Vince, I don't think Google removed anything from the Android kernel that would make it unable to run stock Linux applications. They did add functionality (the IPC binder, their own power manager, etc.). You should be able to take an Android kernel, remove the entire Android userspace, and boot a standard Linux system on top of it.
In the userspace, Android currently uses its own C library which is missing many functions that are in the standard glibc used by Ubuntu, etc.. Additionally, the Android userspace assumes it's in control of the whole system. So you might consider how the pieces above the kernel might need to change or be massaged to do what you want. One first step I could recommend is to compile a hello-world 'C' program that you are able to run inside the Android emulator. That should give you some pretty good ideas about how the pieces fit together. Regards, Peter On Jan 19, 2009, at 9:54 AM, MyLinuxSupport wrote: > > 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 <[email protected]> wrote: >> Andrew, >> >> On Sat, Jan 17, 2009 at 2:41 AM, drew <[email protected]> >> 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 <[email protected]> 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 <[email protected]> >>>> 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 <[email protected]> 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 <[email protected]> >>> 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: [email protected] website: http://groups.google.com/group/android-porting -~----------~----~----~----~------~----~------~--~---
