On Wed, Jan 21, 2009 at 12:22 PM, Jean-Baptiste Queru <[email protected]>wrote:
> It's not that easy, because aapt assumes that the android package name > is also the source code package name. At the very least you need a > custom post-processing step to move the generated R file into the > proper source code package, and none of the standard Android build > tools support that. Yes, better tools to help with this would be nice. The basic point of the package name is this: it provides a unique identity for an application under a particular author's control. It does not make any sense for someone to go and modify an application in the open-source platform and make it available with the same package name, because what you have done is created a -fork- and it needs a new identity. The existing system app will continue to evolve, and your own fork will continue to evolve, and there is no way to ensure they are compatible. And further, as I said, the apps that are available as part of the platform code are really owned by the manufacturer of the device they are running on (using the platform code as a base), so there is simply no way you can know that your version of the app forked off of some version of the platform will be able to actually replace the version built into a piece of hardware based on possibly some other version of the platform with who knows what customization done by the hardware manufacturer. So the way one replaces components is to create a -new- application that supplies the same features to the system as the built-in application, so the system can let the user pick which one to use where appropriate, use the built-in one where the replacement didn't actually happen to provide some functionality it has, etc. This is actually an -intrinsic- part of the claim about third parties being able to replace applications, in that it is done in such a way that it can be controlled and avoid breaking things on whatever device the replacement is being installed on. > On top of that, you've got to pray that the application you're working > with only uses SDK-accessible permissions. The vast majority of applications built into the system use normal application permissions. As we have already gone over numerous times, yes there are some parts of the UI that are more intimately tied with the system (in-call screen, lock screen, settings) and not so easy to extract at this point. That doesn't invalidate the general philosophy nor the extensive architecture in place to support that philosophy. -- Dianne Hackborn Android framework engineer [email protected] Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
