On Mar 24, 7:03 pm, Mark Murphy <[email protected]> wrote: > Jargon wrote: > > We are investigating the possibilities to package & deploy platform UI > > extensions which can contain both Java code andresources- which then > > can be (re-)used by applications using <uses-library> tag in the > > AndroidManifest.xml. > > You and me both, though I'm not trying to use <uses-library>. > Can you explain more of your strategy - and how to avoid platform changes? My initial plan is to do very small changes in the platform to enable vendors to build their own resource packages, just as framework-res.apk, since most of the stuff already seems to be there. Then looking into a more long- term solution which eliminates the "unique package identifier" issue which in inevitable, basically by replacing the top 8 package bits in the resource identifier with a namespace identifier, e.g. "com.vendor.foo". Such a solution would enable introduction of third party packages just by adding them into the file system since their resources would not clash with existing ones.
> > > One solution which has been discussed was to use the aapt -x option > > together with the new --custom-package option introduced in November > > to generate unique resource identifiers for the shared resource > > package. > > That's interesting -- I had not noticed --custom-package before. I will > need to do some experiments to see if this helps with the solution I'm > working on. > This fix enabled us to use the aapt tool as is, without any patching. Still we are considering another option --custom-package-id which would enable finer control of which package identifier is assigned to the generated package. > > Then, just as the <uses-library> information in the manifest file > > would bootstrap the class loader with the listed extension packages, > > it would add these packages to the asset manager as well - allowing > > the asset manager to locate and load the extensionresources. (This > > would require a platform extension.) > > I'm trying to avoid anything that requires modifying the SDK, and I > agree that overloading <uses-library> this way would require such > modifications AFAIK. > We were considering introducing a <uses-resources> tag but this would require a lot more changes. To me, it feels natural to think that a library could hold both code and resources. > > So, my question is really if this is a way forward - using the 8 > > package bits in the resource identifiers? > > What are the "8 package bits"? > Each resource identifier consists of 32 bits were 8 top bits defines the package in which the resource belongs to. Platform resources are 0x01 and 0x7F are application resources. The idea is to use the remaining 253 values for extension packages. > > This solution would probably > > work initially for one vendor since the allocation of unique package > > identifiers would be an internal issue, but if extension packages > > where to be exchanged within the android community there would be a > > high risk of packages using the same identifiers. > > The issue of identifier collisions is a well-understood one for those > who have done development before with reusable components or modular > operating systems. Everything from Linux's apt and yum to Ruby gems > requires unique identifiers. So long as there are a handful of popular > repositories, "first one in wins" should suffice there. > > Hence, I am not that worried about that aspect of the problem too much. > Whoever comes up with a component packaging system just needs to also > run a repository. > With the introduction of namespace, e.g. "com.vendor.foo" such a repository would not be needed since they would eliminate resource clashing. -- 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 To unsubscribe, reply using "remove me" as the subject.
