Pandora Should Move To Android


Hmmm.. Fifteen pages... I hate to say this, but TL:DR.
I don't think it SHOULD move to Android, but I do think that there should be Android as an option.
 
Exophase said:
Yoyobuae said:
Exophase said:
- But to all the "let's stay with Linux" crowd, Android is still Linux.
Is it?

IMO yes... there are lots of forks of the Linux kernel, maybe not usually as decisive as this but I'm sure even Pandora's kernel hasn't been fully passed upstream yet. To me this is like saying GP2X isn't Linux because it's shipping with an ancient kernel. So long as a fork doesn't strip away major functionality it should still qualify.
I have no issue if Android compatibility is bolted onto our OS... so you can access the Android apps and run them, but to switch to Android completely is just silly.
 
Last edited by a moderator:
craigix said:
Consider:

The Pandora should move to Android to get real commercial software and games - plus it's only a matter of time before someone else releases an Android games console (which works well), Pandora should be first.

Discuss...

exclusively move to? maybe not.
but having Android as a supported OS can't hurt.

as for getting commercial software & games, getting more than 1000 devices out there might help a lot ;)

I got to try barzoule's Pandora at @Party2010 and we discussed making games, the market is still much too small to support pandora-exclusive commercial projects but I'm planning on doing Pandora ports of my games as they're developed under Linux anyway.
I just need my device to test :p
 
Last edited by a moderator:
Jourdy288 said:
Hmmm.. Fifteen pages... I hate to say this, but TL:DR.
Summary so far: (no|yes|ok, but only as an option)*
 
Last edited by a moderator:
Personally, I would not be interested, though perhaps it could be an option.
 
Loonie said:
Personally, I would not be interested, though perhaps it could be an option.

LOL that's a great summary of basically every post in this thread.
 
Last edited by a moderator:
Eniko said:
trix said:
Loonie said:
Personally, I would not be interested, though perhaps it could be an option.

LOL that's a great summary of basically every post in this thread.
There are a few people who don't agree with this view, you know.

Yeah, but their posts got buried so fast by those of us thinking the above, that nobody saw em!
 
Last edited by a moderator:
Exophase said:
Yoyobuae said:
IMO yes... there are lots of forks of the Linux kernel, maybe not usually as decisive as this but I'm sure even Pandora's kernel hasn't been fully passed upstream yet. To me this is like saying GP2X isn't Linux because it's shipping with an ancient kernel. So long as a fork doesn't strip away major functionality it should still qualify.
The link sound like they are using custom API / interfaces. IMHO this is line I draw to take apart what is a simple fork (that will/may be merge back) and something that isn't linux anymore.

When I sugested the idea to use Stuckie extention system, I was thinking about : chroot the whole android image, provide device interface (a few mknod) and force it to use second framebuffer.
But as android is using a custom framebuffer API, that won't work. At least without a large job on the base Android libs. At this point, you're not packaging, you are porting from a plateform to an other.
What I was suggesting was feasible in a reasonable time-frame for an high-level hacker (that's not me, obviously), but with the API changes the timeframe is way less reasonable.
and knowing that the beagleboard team still have no framebuffer for android is a clear indication that the changes are not obvious at all'.
 
Last edited by a moderator:
sebt3 said:
The link sound like they are using custom API / interfaces. IMHO this is line I draw to take apart what is a simple fork (that will/may be merge back) and something that isn't linux anymore.

When I sugested the idea to use Stuckie extention system, I was thinking about : chroot the whole android image, provide device interface (a few mknod) and force it to use second framebuffer.
But as android is using a custom framebuffer API, that won't work. At least without a large job on the base Android libs. At this point, you're not packaging, you are porting from a plateform to an other.
What I was suggesting was feasible in a reasonable time-frame for an high-level hacker (that's not me, obviously), but with the API changes the timeframe is way less reasonable.
and knowing that the beagleboard team still have no framebuffer for android is a clear indication that the changes are not obvious at all'.

To me I think it qualifies as "Linux" so long as the base APIs, syscalls, driver model, etc are still available. I don't know if it's the case on Android, that they're using custom new interfaces on top of everything, or if they have stripped out and replaced things. I'm not trying to force a semantic argument on this, the reason why I think this is relevant is because it dictates whether or not Linux things can be ported to it.

Can you link me to any kind of writeup of Android's framebuffer API? I'm wondering if an emulation device is not possible. You seem to be talking about allowing Android to be ran within a vanilla Linux build like what we currently have. I'm thinking more the opposite, going to an Android that's compatible with current Pandora applications as a Linux substitute (obviously won't work for anything relying on X, but apps using SDL or fbdev/OSS/ALSA/etc straight could).

I'm concerned about any OS options, particularly ones that gain any fair amount of traction, that cause a fundamental software compatibility split. I don't like knowing that, even optionally, the already small Pandora userbase might not have routine access to the same app pool. People will dual boot, but inevitably a lot of them will end up sticking with whatever they use the most, because switching OSes is a pain. So if compatibility isn't there I don't think both should be supported/endorsed options.
 
Last edited by a moderator:
I don't really mind either way but I might be selling my pandora anyhow since I might be needing some cash for real life type of things, it's complicated :)
 
On a long enough time line,



the survival rate for all computers drops to zero.



What are you doing? Come on!



Hands behind your back.
Give me your order number.



Open Pandora Console.
GP32, Apartment X.



- Small, cramped internet forum?
- How did you know?



They give shitty forums letters.



Pandora! You're going to die.



No!



Is that your makers?
They're gonna have to call the technician.



Pick up your circuit schematics. Know why?



- There'll be nothing left of your PCB.
- Oh, come on!



An expired app store url.
What did you compute, Pandora?



- S... S... Stuff.
- Stuff?



Was the coding hard?



- I asked you what programs you ran!
- Emulators, mostly.



- Why?
- I don't know.



What did you wanna be, Pandora?!



The question,Pandora,
was what did you want to be?



Answer him, Pandora, Jesus!



- Open source console. Handheld console.
- Gaming.



- Yeah. Homebrew and stuff.
- Stuff. Yeah, I got that.



- So you need more development.
- Too much coding.



- Would you rather be dead?
- No, please...



You'd rather die here, on your knees,
in the back of a Village Hall?



Please, no.



I'm keeping your order number.



Gonna check in on you.
I know where you live.



If you're not working
to be an awesome games console in six weeks,



you will be dead.



Now run on home.



Run, Forrest, run!



I feel ill.



Imagine how it feels.



Come on, this isn't funny!



What the fuck was the point of that?!



Tomorrow will be the most beautiful day
of Pandora Consoles life.



His assembly code will run better
than any program you and I have ever operated.



You had to give it to him.
 
Exophase said:
Can you link me to any kind of writeup of Android's framebuffer API?
Nothing outside the register link above. I didn't knew before reading this article.
new hooks for its "sometimes bizarre" security model, and a revamped framebuffer driver infrastructure
In fact the last time I checked android, I discovered that they were using their own libc (containing their own threading implementation) , I was gone like "bulls**t, what we needed the most is a 4th opensource libc implementation for the linux kernel, yeahh". So you could guess my knowledge of the actual plateform...

For the rest we basically agree, I was thinking about using our current kernel as writing kernel drivers is not the easiest task on earth.
 
Last edited by a moderator:
When I first read this it was 2 pages deep. It seemed like an intelligent pondering. Now I am wondering if Craig has trolled you all while on break from the assembly line. :unsure: Then again I haven't read much of the other 14 pages of postings, probably just my ignorance appearing in public. Good thing I wear pants.
 
Android Blog regarding app-removal.
The remote application removal feature is one of many security controls Android possesses to help protect users from malicious applications. In case of an emergency, a dangerous application could be removed from active circulation in a rapid and scalable manner to prevent further exposure to users. While we hope to not have to use it, we know that we have the capability to take swift action on behalf of users’ safety when needed.

This remote removal functionality — along with Android’s unique Application Sandbox and Permissions model, Over-The-Air update system, centralized Market, developer registrations, user-submitted ratings, and application flagging — provides a powerful security advantage to help protect Android users in our open environment.
Over-The-Air; centralized; protection!; removal of 'malicious' software... This is just pure evil, even more pure than this interesting ED-pic that's floating around here somewhere.

I... Well... And...

Please don't.
 
I would run android as the main OS if it was offered, it already has all the software I could ever want for a handheld. The one thing my android phones are missing are gaming controls and a keyboard.

I would literally be beside myself in happiness if the latest version of android (AOSP 2.2 froyo) and the market were gotten to run on the pandora.

if there's a dev fund directly related to this project, point me in that direction
 
If anyone wants to play with Android, go ahead: http://developer.android.com/guide/developing/tools/emulator.html You wont get the Market/Google Maps etc though, but you can install apps by their APK's



Best way to proceed is to find out if there are drivers already available for Pandoras hardware. The Motorola Milestone used the OMAP3530 A8 Cortex and full specs can be found here: http://and-developers.com/motorola_milestone:device_information
 
sebt3 said:
For the rest we basically agree, I was thinking about using our current kernel as writing kernel drivers is not the easiest task on earth.

I think not too many new drivers would have to be ported, since there are already OMAP3 Android devices. It would be helpful if something was using the same wifi chip too, in fact very helpful as I think this could a long way towards ironing out remaining wifi software issues. Control drivers, including nub would be on the table no matter what.. and the audio driver, since it's not a standard twl4030 setup. I wonder what kind of audio system Android uses, and if it'd maybe have benefits over what we're using now too (or drawbacks).

Actually, it's strange that Beagleboard isn't ahead of the curve given Droid etc, is there something going on that's not requiring them to share all their hardware support code? Are drivers ending up in userspace?
 
Last edited by a moderator:
Back
Top