Android On The Pandora


Last edited by a moderator:
OWWWWNED! ;)
how was that owned? That was 1 day of android programming progress from the same person that wrote the software for the pandora...


I also provided day 2 progress


here's day three

https://www.youtube.com/embed/DPKdQayVlBc?feature=oembed

I'm just going to step out on a limb and guess the focus is being put into android port rather than the pandora port at the current time being. That may not be 100% true or accurate, it just looks that way.
 
I'm just going to step out on a limb and guess the focus is being put into android port rather than the pandora port at the current time being. That may not be 100% true or accurate, it just looks that way.
Does it matter?


The important part is the dark low level magic, and that should run without any problems on the Pandora as well. He's still developing for a Cortex-A8, OpenGL ES hardware and a Linux-backed system after all.
 
Does it matter?


The important part is the dark low level magic, and that should run without any problems on the Pandora as well. He's still developing for a Cortex-A8, OpenGL ES hardware and a Linux-backed system after all.
It doesn't matter at all, you are completely correct, but I was responding to him making a big deal that version was running better on angstrom.


What I see right now is that it looks like the primary effort was on the android version, I am waiting on my pandora, but I have my android device now. If the pandora never sees android I would hope the updates filter down to the angstrom version, but from what I see right now, I can have those updates on the android version, no hope required ;)
 
I think the difference between the Pandora and Android version of nullDC is just in the makefile…


Android and Angstrom are fundamentally linuxes running on arm cpu devices.


So it doesn't matter on which it's built and tested, both will be improved.


And I think it's better to start working on Android because it's the platform that have the less liberty and the most various hardware.


So once it'll work well on Android devices, we'll be just a "make" away from a PND nullDC.
 
I think the difference between the Pandora and Android version of nullDC is just in the makefile…


Android and Angstrom are fundamentally linuxes running on arm cpu devices.

Well, is nullDC running natively, or in Java? If the latter, then obviously it's a completely different source tree.
 
Well, is nullDC running natively, or in Java? If the latter, then obviously it's a completely different source tree.
I almost have to believe it's core is built in NDK wrapped in a Java loader. If so, that core code should be pretty compatible with the Pandora. Perhaps the front end graphics and stuff need to be rewritten, but the recompiler should be the same, maybe, I hope.
 
I would still like to see a WINEesque wrapper for Android apps to run in. I.e. a layer to handle the system calls (and re-direct them as appropriate) instead of running the whole OS. Essentially 'fake out' the missing hardware.


Android app uses the accelerometer? Fine - interpret nub movement and tell the app that it is accelerometer input.


Android app uses GPS? Fine - give the user two alternatives: Input from a bluetooth/USB GPS unit OR to input a static Latitude/Longitude location as the 'default location for Android apps'.


Android app uses the camera? Fine - redirect it to a static image file or a USB connected camera.


Ideally the interpretive layer would make the app think it's running directly on an Android device.


That leaves connection to the marketplace itself. How to handle that depends on if/how the marketplace handles things.


Ideally these interpretive environments could be set up to handle anything compiled for an ARM platform. So, iPad, Android, etc applications could theoretically be able to be housed on a Pandora. Since they would have direct access to the ARM CPU, they wouldn't really be emulators, but interpretive layers.


Of course, that can all be filed under the 'Dream' section for now.
 
Ideally the interpretive layer would make the app think it's running directly on an Android device.


That leaves connection to the marketplace itself. How to handle that depends on if/how the marketplace handles things.
a wine-line layer would be good, but I see that being a serious pain in the butt to maintain and it's not a guaranteed 100% compatibility. I would believe a one time port to a semi recent version of android would be easier than constantly modifying and improving that wine-like layer. It's extremely possible that the pandora won't meet the minimum system requirements for future version of android. Space wise the basic rom with Google apps fits in approximately 90mb. All additional apps from the market can be stored on your SD card(s)


the key to the android marketplace is getting google talk to work. It basically uses that service and rides on xmpp to the google servers to authenticate you and track what you're buying and downloading. The build.prop file tells the market which device you are useing and what software is compatible with your hardware. If for some reason you see "most" of the apps in the android market but not all it's because your build.props file is dorked up.
 
Has anyone managed to get this working on the pandora


with a download
 
Last edited by a moderator:
I posted another thread about this, but I see potential for what I want in this project: THere is a version of Kindle app that runs under Android. If Android OS is ported to Pandora (maybe via a bootable SD card), would it have access to the wifi onboard Pandora to access the Amazon Kindle storefront to download books?


Maybe a pipe dream of mine, but I look forward to tracking progress of this and keeping my fingers crossed!
 
Back
Top