Hello David, In the networking world sockets are used locally as IPCs to enable applications to communicate locally or over the network as configured. Many people assume that whether IPC communication happens locally or remotely is and should be a configuration choice. With cellphones having more power and storage then 1990's mainframes, optimizing local IPC communication doesn't seem like a necessity for a client device at the expense of compatibility. Cell phones are replaced approximately every 9 months so if you look 2 product cycles out an average consumer cellphone will have immense power. (Sorry for the rant, I'm sure you guys have your reasons but please don't break existing things unless absolutely no other choice exists).
If we compile the Binder into a standard stock Linux image (Ubuntu, Debian, etc..) and port Dalvik then the rest of the changes don't seem major. This would immediately enable all sorts of things that are missing from the Android OS kernel including drivers and apt-get... Isn't this a faster route then modifying the android kernel to support stock linux functionality? Kind Regards, Vince On Jan 17, 3:12 pm, David Turner <di...@android.com> wrote: > Andrew, > > On Sat, Jan 17, 2009 at 2:41 AM, drew <andrewjohnyo...@gmail.com> wrote: > > But I do have a question, isn't the IPC a standard that's already > > being used for SIP phones and even your normal Telecom Provider? And > > if, just if, my base premise is correct wouldn't that mean that the > > current kernel just needed extending to support a low level or driver > > level routine for the IPC instead of having to rewrite most it? I'm > > not a linux core guru or anything but isn't it also possible to add/ > > extend modules if or when those routines are already existing. > > I have no idea what IPC you're talking about. IPC is a generic term > for Inter-Process Call, used to describe various different ways for > processes on the same machine to talk to each other. When different > machines communicates, the term "networking" is used instead :-) > > In this context, the Binder is an Android-specific IPC mechanism > that is not normally part of a standard Linux kernel (though it could, > it all depends on who distribute the kernel image). > > I really don't see a connection with SIP phones or Telecom Operators > here. Can you be more specific about what you're talking about ? > > > > > On Jan 15, 10:15 am, Jean-Baptiste Queru <j...@google.com> wrote: > > > Many critical aspects of Android deeply rely on having those custom > > > modules in the linux kernel, since that's how the entire IPC mechanism > > > works. Without that, no content providers, no services, etc... There's > > > therefore little hope of getting a multi-process Android running on > > > top of a linux kernel that wouldn't have those modules. > > > > JBQ > > > > On Wed, Jan 14, 2009 at 4:56 PM, drew <andrewjohnyo...@gmail.com> wrote: > > > > > Peace! > > > > > @David Turner > > > > I think you've thought of this already and made a lot of pros and > > > > cons, thanks ... I think your right, my boss thinks the same way that > > > > running Dalvik VM on Ubuntu would be a good route to take. > > > > > Personally I've been trying to recompile the EeePC Android and banging > > > > my head to try to add an editor (like vim or vi or nano) to the > > > > installer created so that when we do an Alt-Ctrl-F1 we can probably > > > > edit some of the init files (like fstab to auto mount a flash drive > > > > to /sdcard so that you can "trick" Android into thinking that there's > > > > a SDCARD present). I already found out that the core linux detects the > > > > USB device but automounting it to /sdcard is not done. Or maybe add a > > > > apt-get module (if that's even possible). > > > > > Currently the EeePC compilation gives you a good foundation of Android > > > > running on a 701 unit, but I'm having a hard time figuring out how to > > > > test the webcam, usb storage, and usb devices (GSM modem). Manually > > > > mounting a usb flash drive does not seem to trick Android to seeing a > > > > storage mounted on /sdcard which is really frustrating. > > > > > If you can guide me to discussions that can help me pursue my current > > > > route of activating these modules for the EeePC that would be great > > > > (ergo my thoughts that compiling Android on top of a Full blown Linux > > > > distro would have helped but like you said reconfiguring the plumbing > > > > to have Android work on a full blown linux distro is going to take A > > > > WHOLE LOT of work with little benefits since the current EeePC is just > > > > needs a bit more work to have these services done) > > > > > @Midhun Agnihotram > > > > Thanks for the reply but I was thinking more of having Dalvik and the > > > > "GUI" Android running on a full blown version of Linux wherein all the > > > > standard device support (e.g. webcam, usb, serial port) is already > > > > there and you can basically edit any of the init files to try to make > > > > Android think it already has an SDCARD mounted on sdcard. Like what > > > > David Turner is thinking of. > > > > > But again thanks for the input, I really appreciate it :) > > > > > If anyone else have thoughts on the topic please do put in your two > > > > cents :) Again Thank you for taking your time to enlighten me on this > > > > topic > > > > > Sincerely, > > > > --- > > > > Andrew > > > > > p.s. > > > > Personally I wished that Google didn't redo the linux kernel variables > > > > and have Android running on a standard cut down version of Linux (any > > > > of the small distros or Ubuntu mobile) so that we can test out Android > > > > running on other different distros but still have the same Google > > > > API's which is WONDERFUL :) Maybe running Android on Ubuntu mobile > > > > (without the ubuntu mobile GUI, I mean making Ubuntu mobile as a base > > > > then have Android running on top :) ). But again I could be wrong, but > > > > that's just my wish. > > > > > On Jan 14, 6:17 pm, David Turner <di...@android.com> wrote: > > > >> On Linux, it is possible to build the Android simulator, which runs > > many > > > >> parts of the platform in a single Unix process (so no real security > > for > > > >> you), doesn't use the custom C library, etc... > > > > >> if you don't want to go this route, you will need to patch your kernel > > to > > > >> integrate a few Android-specific things like the Binder driver. > > > >> second, Android expects system files in different places, comes with > > its own > > > >> init program and scripts, etc... > > > > >> running the whole of Android on top of a standard Linux installation > > will be > > > >> a lot of work with probably few benefits. You should probably try to > > get the > > > >> Dalvik VM running first on Ubuntu plus some of the system libraries > > that > > > >> don't depend too much on Android-specific behaviour. > > > > >> On Wed, Jan 14, 2009 at 9:52 AM, drew <andrewjohnyo...@gmail.com> > > wrote: > > > > >> > Peace All! > > > > >> > Hi, has anybody tried to compile Android on top of a full blown > > linux > > > >> > distribution like ubuntu? > > > > >> > My rationale is that if we do get this thing to work and then attach > > a > > > >> > GSM modem (usb or serial port type) with excellent AT command > > > >> > documentation, we can really do some serious movement in terms of > > > >> > turning a netbook or a good smartphone into a single port VOIP > > gateway > > > >> > or have applications work over the actual voice channel (not the > > > >> > digital voice channel) and record conversations. > > > > >> > For netbooks (if we can figure out how to lower the power > > consumption > > > >> > problem so that a netbook can last as long as an acceptable > > smartphone/ > > > >> > mobile phone) with the GSM modem, there's a ton of possibilities and > > > >> > products that can come out of it. (e.g. you can have bluetooth to > > > >> > answer your calls and take down messages for you from a good PC > > > >> > powered voice recognition software) > > > > >> > I know I must sound crazy but I do think I have something here. > > > > >> > Sincerely, > > > >> > --- > > > >> > Andrew > > > > -- > > > Jean-Baptiste M. "JBQ" Queru > > > Android Engineer, Google. --~--~---------~--~----~------------~-------~--~----~ unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting -~----------~----~----~----~------~----~------~--~---
