P2: Integrating Android and Linux

[klapse]

I'm not into Androids inner works so forgive me if the question is stupid, but what about the mechanism/resources that outreach the "simple" functionality of a vm? Wouldn't we need all the filesystem structures, databases, etc. and does this bear possible conflict potential with the Linux distribution used in parallel / as host

I'm also not an android developer so take this with a grain of salt.. the mainlining project http://elinux.org/Android_Mainlining_Project has a chart of all Android kernel features which need to be supported.


Then there is the dalvik vm which needs to be compiled for the system (not a problem).


Then IF there are any standard system libraries which android has modified to be incompatible with the linux ones, these need to be LD_PRELOADed before executing the android app in question.


Not sure how input and sound/video output would be arbitrated. THP's apkenv seems to do it already.


Would help if we had an android dev here to explain more.

 

[Grench]

If Num4 can be done as Grench describes, then that would be a rather impressive feature and sure to be a selling point... especially if Craig actually *does* put 8Gb ram in there like he said he wanted to. Then, theoretically you should have no problem suspending whichever OS that isn't being used to ram. Wouldn't that free up the fourth core if needed? How fast would one be able to switch between OS's this way? I would assume one could easily copy/paste info between the OS's?


But personally I would have no problem with dual-boot.

In theory, since both OSs would be live and running, you should be able to switch back and forth just as fast as the video buffer can re-load.


Copy/paste would require some form of integration/translation on the Hypervisor to make happen.


Thinking more on this though...


The hypervisor would have to manage all of the root drivers for all of the components on the machine then pass this back to each OS. VirtualBox and VMware have a difficult enough time doing this on X86 for the easy ones - USB, networking (hypervisor virtual bridge) video and audio. This is the part that has me hesitant on #4. There is a lot going on there. Probably more than a company flying by the seat of it's pants would want to take on - and very thankless work for any volunteer devs.


Dual boot is the next option.


If we use internal NAND, we'll need 8GB of it per OS - and the ability to partition the NAND. So, 16GB NAND?

 

[fritata]

It would probably be better to have option 1 for the non-android users.

 

[FaeMinx]

16gb of NAND would be impressive... But wouldn't it be really expensive? Wouldn't an internal microSD be a better solution here?


Sent from my HTC Sensation Z710e using Tapatalk 2

 

[vcoleiro1]

Nand these days is relatively cheap. 16GB would be about $10

 

[FaeMinx]

Well in that case... How much is 32gb? ^.^


Sent from my HTC Sensation Z710e using Tapatalk 2

 

[vcoleiro1]

^


From the iPhone component costing breakdown they did a while back


$11 16gb


$21 32gb


$42 64gb

 

[rohezal]

Just take number 1. The people who wants the shiny mobile / tablet os can use it. The people who want a real linux distro can use the later one. Everything is fine .

 

[klapse]

Just take number 1. The people who wants the shiny mobile / tablet os can use it. The people who want a real linux distro can use the later one. Everything is fine />.

And the people who want to use both would have to reboot...


Options 2, 3 and 5 would allow running linux and android apps side by side. If the P2 were the first commercial device that supported that out of the box, it would get a write-up on every tech blog, every linux magazine etc etc. It would be huge news that would yield more free advertising than any other feature.


edit: here is a nict chart of the components of a linux+android merged OS.


http://techie-buzz.com/mobile-news/android-mainlining-project-takes-android-back-to-the-source.html

 

[Grench]

^


From the iPhone component costing breakdown they did a while back


$11 16gb


$21 32gb


$42 64gb

If the NAND can be faster than a microSD, and if it can be paritioned, then load the boat with 64GB.


If it's a wash speed and space wise between on-board NAND and a microSD card, use the card.


Here's the rub though. If I understand it right, that could limit us to one exposed SD slot as the OMAP5 only allows for two SD slots. If that is the case, then using a microSD in place of NAND could seriously limit the device's computer based functionality.


I think I may have spotted a way out though. If you look at the OMAP5 diagram:


http://www.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123&navigationId=12863&contentId=103102


Note that it has a SATA 2.0 header on it. If we make the device just 10mm thicker, we could add a big SSD to it...


Oh, wait, that goes the entirely wrong direction.


It would be rather entertaining to have the SATA 2.0 port brought out to the back of the device as an eSATA though.

 

[Exophase]

You can get a 64GB USB flash drive for as low as $30 now, so the raw price of NAND has to be less than that. I don't think Apple is paying a premium for higher grade NAND, I think the numbers are just not current.

Here's the rub though. If I understand it right, that could limit us to one exposed SD slot as the OMAP5 only allows for two SD slots. If that is the case, then using a microSD in place of NAND could seriously limit the device's computer based functionality.

I'm pretty sure it'll support at least 4 SD slots because those two SDIO ports in the block diagram can probably be used for SD. Actually, since MWeston has described a design w/internal microSD + two external microSD I'm pretty certain it can be done. Only two SD would be a major regression vs OMAP3 which has 3 and OMAP4 which has 5.


OPT should avoid soldered on NAND if they can because it'll make it more expensive to manufacture and maintain. Not really sure why you're happy with 64GB builtin NAND when earlier you were pretty adamant that you wanted full SD for the boot card so you could boot 128GB+..

 

[Lao Rebel]

i prefer dual boot. i don't trust Android as it is a corporate sponsored OS. i love my linux and one of the reasons i bought a P1 was b/c it is a linux machine.

 

[Grench]

You can get a 64GB USB flash drive for as low as $30 now, so the raw price of NAND has to be less than that. I don't think Apple is paying a premium for higher grade NAND, I think the numbers are just not current.

Here's the rub though. If I understand it right, that could limit us to one exposed SD slot as the OMAP5 only allows for two SD slots. If that is the case, then using a microSD in place of NAND could seriously limit the device's computer based functionality.

I'm pretty sure it'll support at least 4 SD slots because those two SDIO ports in the block diagram can probably be used for SD. Actually, since MWeston has described a design w/internal microSD + two external microSD I'm pretty certain it can be done. Only two SD would be a major regression vs OMAP3 which has 3 and OMAP4 which has 5.

Then it should be a non-issue to put a 3rd card in instead of on-board NAND.

OPT should avoid soldered on NAND if they can because it'll make it more expensive to manufacture and maintain. Not really sure why you're happy with 64GB builtin NAND when earlier you were pretty adamant that you wanted full SD for the boot card so you could boot 128GB+..

Sure, I can clarify that.


If it's going to have NAND on the system board, fill the boat.


I want to run the OS from the fastest 'drive' possible.


Onboard NAND direct-attached to the SoC can be faster than any SD permutation.


If we're going to skip on-board NAND I would like to be able to use the fastest SD media available. That would normally dictate a full sized SD card.


So, in my humble opinion:


(64GB on-board very fast direct attached NAND + 2SD slots) > (3 SD slots) > (1 microSD + 2 SD) > (2 microSD + 1 SD) > (3 microSD) > (2 microSD) > (1 microSD)


All seemingly irrelevant given the other discussions going on that threaten to nix a CraigIX P2 from having ED & community input.


It would be interesting to see what CraigIX would come up with Vs an incremental step forward using as much current stuff as possible. There may be none, one or two kinds P2s as the road ahead appears to have a fork in it.

 

[SNESFAN]

micro/full sd card (my god.. it spreads to every topic) anyway... couldn't this be the solution to the problem but in reverse for people that want full sized cards?


http://www.instructables.com/id/Shrink-Your-Raspberry-Pi-With-MicroSD-Card-Slot/


if the space is truly not a concern it shouldn't matter right? just make the holder/cage hot swappable, ideally IMO the internal should be accessible/removeable under the battery only and if enough surface area of the PCB is exposed the size of the cage shouldn't be a problem. If space is an issue, then maybe sell a case mod that allows for the extra room by making some kind of common connection cable or something and move it away from the PCB


That idea would spawn off even further to those that want more than normal stock configuration if the chipset allows it. Add leads on the board for the possibility to add as many additional ports as the chipset allows as "external sd card ports"


Back on topic, dual boot but with the option to set a primary, or only flash the OS of preference if desired for those that have no interest in the alternative

 

[EssoAir]

As most, I think that number 4 would be amazing, but that seems like a lot of work for not much gain. If the devs were willing, then I'd be all for it. But before they do it, they would need to commit to being able to manufacture a LOT of P2s. Because if they got number 4 working well, then literally anyone that wants a pocket pc, anyone that wants a classic gaming device, and anyone that likes to tinker with devices (like most XDA-Developers forum members) will want a P2 which means that either the device will sell out in 20 minutes, or they need to manufacture hundereds of thousands of devices.


Crossing my fingers that option 4 actually happens and the P2 becomes as main stream as the iPad and Nexus 7.

 

[klapse]

I'm a bit surprised that the mainlined android+linux kernel is getting so little attention: it could allow for android and linux apps running side by side. The hypervisor option would require switching between the two OSes.


For the most integrated user experience, the myriad dalvik or linux under android solutions also have their appeal. Given the limited developer resources, some form of turnkey solution might be the only realistic option.

 

[EssoAir]

I'm a bit surprised that the mainlined android+linux kernel is getting so little attention: it could allow for android and linux apps running side by side. The hypervisor option would require switching between the two OSes.


For the most integrated user experience, the myriad dalvik or linux under android solutions also have their appeal. Given the limited developer resources, some form of turnkey solution might be the only realistic option.

Personally, although running apps side by side would be nice, I don't ever see myself doing that. However, if you could make it so that I could launch Linux apps from an Android launcher and have them show up in the ICS multitasking window thing, that would be the most epic device ever.

 

[klapse]

and then there is also


7) OpenMobile's ACL to run android apps on Tizen / Linux


http://openmobileww.com/blog/tag/acl-for-tizen/


"We will be demonstrating Android Apps running on multiple Linux-based operating systems on a variety of devices: Smartphones, Tablets, Set Top Boxes, and In-Vehicle Infotainment systems. Remember that in the current marketplace, consumers want Apps on every device – now you can give your customers their favorite Android Apps regardless of your device or operating system.


If you are interested in enabling Android Apps to run on your non-Android platform, contact our Vice President of OEM Sales, Roger Carlhammar, at rcarlhammar@openmobileww.com to set up a meeting. We would be happy to meet you at our CES booth, or at the GENIVI Partner Showcase (January 7th to 9th) if you are interested in ACL for IVI. Contact us today!"

 

[3_bit]

As long as there is no slowdown when we need the power, I'm fine with it.

 

[ryan27968]

i think if number 4 could be implemented properly and effectively it would be best, otherwise no 1.