On point 3 for example, let's consider the current firmware file is 51 megabytes in size. How much more in terms of filesize for the firmware would you think adding support for Android applications would add to that firmware file. Or could Archos somehow add just small functions to the main firmware file that would load another sort of cryptographically signed image file every time the user clicks on the Android icon, and that this second image file would kind of emulate the Android OS to run those Android applications.
If it's just a case of supporting 3rd-party apps written for Android, and not the UI and services, then all that would really have to be implemented is the JVM and supporting libraries. I suppose you'd have to implement at least some rudiments of the UI, or at least map them onto the existing Archos UI, or onto Qt or something, but I can't see that being a huge job. Embedded JVMs usually need 5-10Mb, but I haven't looked specifically at the Android one.
The problem is that if Archos wanted to do this, and they didn't implement the _whole_ Android Java API, then you'd still end up in a situation where some apps work and some don't (rather like the situation we currently have with Flash
) Take the situation with files, for example. The JVM implementation could
take a request from an app to open a file "/x" (for example) and make it relative to some private directory. With careful programming that would prevent an Android app roaming about the filesystem looking for hacks. But it would still break apps that expect to be able to read and write the underlying filesystem -- and many will, I'm sure.
The problem is that Android was never intended to be deployed and closed, proprietary devices. There's really no support for this sort of thing within the Android APIs. See this statement from the official Android FAQ:
``As an open platform, Android allows users to load software from any developer onto a device. As with a home PC, the user must be aware of who is providing the software they are downloading and must decide whether they want to grant the application the capabilities it requests. This decision can be informed by the user's judgment of the software developer's trustworthiness, and where the software came from.''
In other words, the Android model allows for _any_ software to be deployed, and it's up the _user_ (not the platform) to decide what that software can and can't do. There isn't really any provision for the platform to make those decisions on a global basis.
As I've said before, Archos could, if it wanted, provide an Android implementation that ran alongside the stock Archos environment, but completely distinct from it. It could do this using some sort of multiple-boot arrangement, or by running Android inside a virtual machine. But these are difficult things to do, requiring time and money. If they just want to implement the Android application-facing API, then that means integrating it into the existing Archos environment, and that means facing up the security problems which you get running an `open' API on a `closed' platform.