60293197379e522c870c4a28462804207bab505d |
|
22-Oct-2014 |
Adam Lesinski <adamlesinski@google.com> |
Added some more Split density tests Change-Id: I3b83515f1240e713bbcff5385cf054bba693f297
/frameworks/base/libs/androidfw/tests/data/basic/build
|
82a2dd8efe48d3a4e04655f01329da857ace4b7d |
|
18-Sep-2014 |
Adam Lesinski <adamlesinski@google.com> |
Fix backwards compat problem with AAPT public attrs AAPT has traditionally assigned resource IDs to public attributes, and then followed those public definitions with private attributes. --- PUBLIC --- | 0x01010234 | attr/color | 0x01010235 | attr/background --- PRIVATE --- | 0x01010236 | attr/secret | 0x01010237 | attr/shhh Each release, when attributes are added, they take the place of the private attributes and the private attributes are shifted down again. --- PUBLIC --- | 0x01010234 | attr/color | 0x01010235 | attr/background | 0x01010236 | attr/shinyNewAttr | 0x01010237 | attr/highlyValuedFeature --- PRIVATE --- | 0x01010238 | attr/secret | 0x01010239 | attr/shhh Platform code may look for private attributes set in a theme. If an app compiled against a newer version of the platform uses a new public attribute that happens to have the same ID as the private attribute the older platform is expecting, then the behavior is undefined. We get around this by detecting any newly defined attributes (in L), copy the resource into a -v21 qualified resource, and delete the attribute from the original resource. This ensures that older platforms don't see the new attribute, but when running on L+ platforms, the attribute will be respected. We still need to address this problem in the platform moving forward, as this will only help us in the transition from pre L to L. Bug:17520380 Change-Id: Ia2a985798b50006c21c7c3431d30d9598f27cd91
/frameworks/base/libs/androidfw/tests/data/basic/build
|
833f3ccbc8f4dd1ec8abb9121988b99ff34ec4c1 |
|
19-Jun-2014 |
Adam Lesinski <adamlesinski@google.com> |
AAPT support for feature splits This change allows the developer to add a base package for which to build a feature split. The generated resource types will begin after the base APK's defined types so as not to collide or override resources. Multiple features can be generated by first choosing an arbitrary order for the features. Then for each feature, the base APK and any preceding features are specified with the --feature-of flags. So with a base APK 'A' and features, 'B', and 'C', 'B' would be built with aapt package [...] --feature-of A [...] and 'C' would be built with aapt package [...] --feature-of A --feature-of B [...] Change-Id: I1be66e3f8df9a737b21c71f8a93685376c7e6780
/frameworks/base/libs/androidfw/tests/data/basic/build
|
f90f2f8dc36e7243b85e0b6a7fd5a590893c827e |
|
06-Jun-2014 |
Adam Lesinski <adamlesinski@google.com> |
Support multiple resource tables with same package In order to support APK split features, the resource table needs to support loading multiple resource tables with the same package but potentially new set of type IDs. This adds some complexity as the type ID space changes from dense and ordered to potentially sparse. A ByteBucketArray is used to store the type IDs in a memory efficient way that allows for fast retrieval. In addition, the IDMAP format has changed. We no longer need random access to the type data, since we store the types differently. However, random access to entries of a given type is still required. Change-Id: If6f5be680b405b368941d9c1f2b5d2ddca964160
/frameworks/base/libs/androidfw/tests/data/basic/build
|