A sentinal value of 0x00000000 was used to mark the first time an AttributeFinder
was used. If the resource ID of an attribute was also 0x00000000 (which occurs with
non-resource attributes, like 'style'), then it would be mistaken as the sentinel
start value.
Bug:18421787
Change-Id: I4be353e0f8c940cb6f262d155129f048dcc444ae
Private attributes are typically placed after public
attributes in the resource table. Each time a new version
of the Android framework is released, new public attributes
take the place of the private attributes, and the private
attributes are shifted after the new public ones.
This means that any apps built against the newer SDK
may inadvertently be using private attributes on older
devices.
This change moves all private attributes to a completely
different type ID, so there will never be collisions across
versions.
These private attributes are automatically moved to a synthesized
type only for the system resources.
Bug:18263655
Change-Id: I7a850512953fadcc9f3524d509cea30249782db8
System overlays, ie overlays with targetPackage="android", were loaded
twice, which caused all sorts of issues. Ensure they are only loaded
once, which will be during Zygote initialization.
Bug: 17765434
Change-Id: Ia5064045c77f713c58fb78adc3942f6af1abdc93
In the new idmap format (version 0x1), 0x00000000 no longer represents a
non-existing entry: 0xffffffff should be used instead.
Bug: 17765434
Change-Id: If2c7e09feba2224eeafe88fd9230e6392d81b9a7
With the recent introduction of AssetManager::appendPathToResTable,
overlay packages were not properly added to the AssetManager, and once
added, were not properly inserted into the ResTable.
Bug: 17765434
Change-Id: Ie21f227c654c98730f74a687d0e16ee2b80e747e
Shared libraries have their package ID assigned at run-time, so some
of the guarantees we used to have about sort order of attributes in
bags or XML elements no longer hold.
This CL adds back-tracking and can jump to the nearest attribute with the
same package ID and continue searching.
This means that attributes with the same package ID must be sorted by increasing
resource ID, as was the case before.
Attributes with the same package ID must be grouped together, but the groups can
be in any order. Ex: 0x02010001, 0x02010002, 0x01010000, 0x01010010, 0x7f010032
Bug:17666947
Change-Id: I9c198bbb6ca788849aac85b6323606ea5d9550d6
- char16_t is a distinct type, so stay consistent
with it throughout the code base.
- char16_t is defined as minimum size of 16 bits.
Since we mmap and cast data structures onto raw memory,
we need a precise definition (uint16_t), so we cast between
that (and static_assert that they are the same size).
Change-Id: I869c32637543bbcfb39d2643e7d9df10d33acd3c
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
