Previously we would stop at the first match when looking for a type string,
but we should search all packages in case a feature Split added a type
with the same name.
Bug:17924027
Change-Id: I6bc7ef073324db99448538cd8bdf566658f066ff
The attribute name resource IDs were never fixed up with
the runtime package ID so we weren't finding attributes
whenever the runtime package ID was different than the build
time one, which happened to be when a shared lib referenced itself
(0x00 vs 0x02).
Bug:17666947
Change-Id: Icf3e874bcea0e27eebe42d60fbed626a34bf9266
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
The build system takes care of linking the correct STL and gtest
libraries for you, and specifying them manually confuses the build
system when using libc++.
Change-Id: I9f76ab26a63ace51293614cfb5ca002f37438e02
When compiling in C++ mode, the compiler will complain about conversions
from uint16_t to char16_t. Be consistent in using char16_t for strings.
Change-Id: I052b6176ced635162920b31560052d9a64f92764
The versionCode of theframework resources that an app is built against
gets stamped inside an app's AndroidManifest.xml in the <manifest>
tag as "platformBuildVersionCode" and "platformBuildVersionName"
attributes.
Bug:17207635
Change-Id: Id573c3dffcbca38eec9c0eb3e89f4a547e3361d3
This is meant to be used with scaleable vector
drawables, and are chosen as the best match unless
there is a configuration that matches the density
requested exactly.
Bug:17007265
Change-Id: Ic3288d0236fe0bff20bb1599aba2582c25b0db32
Packages without any resources should not expect to have
a DynamicRefTable.
Bug:16895517
Bug:17056720
Change-Id: Id006f6bdbf08f30505f6ba5982bc9d1b09db0f0a
When a String isn't found in the StringPool,
we should not try to construct a String8 object
from the NULL string.
Bug:15163956
Change-Id: I51e701918b10a72c18a860b8a36dce2afd9c0b82
This reverts commit 0e475302cd196f45a01a525c49089018b238d4ba.
I'll re-upload this CL with the correct fix in LoadedApk.
Change-Id: I17c6381f8e5907dab9f996f89c5d435b9c08a13a
All APKs are expected to have at least one resource table (even if
it is empty). We were missing the creation of an empty DynamicRefTable.
Bug:16895517
Change-Id: I6a6e887f91b3b4bbcc52b3fd2741ef3d05fab1fd
A ResTable_map entry has a name attribute, which
could be a dynamic reference if it comes from
a shared library. It was not being patched with
the correct package id.
Bug:16795890
Change-Id: Ia8df6a943269b2fefb2132c3ed74eb1997d7701b
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
