To allow apps that compiled against a pre-release SDK to continue
working for a period of time after API finalization, a new tag,
<staging-public-group-final>, has been added to aapt2.
When finalizing the framework resource API, converting
<staging-public-group> tags to <staging-public-group-final> will
cause aapt2 to generate the resource table so that there is a resource
entry for the old non-finalized (staged) resource ID and another entry
for the finalized resource ID of newly finalized resources. This allows
an application that compiled against the pre-release SDK to continue
resolving resources using pre-release resource IDs.
All references to pre-release resource IDs will be rewritten to their
finalized resource IDs through the information stored in the new staged
alias chunk. This allows applications compiled against
<staging-public-group> resources to use the newly finalized
resource ID without re-compilation.
When an application is re-compiled against the SDK with
<staging-public-group-final> tags, the application will use the
finalized resource IDs.
This change limits the use of the alias chunk to the framework for S.
Bug: 183411356
Test: aapt2_test
Change-Id: Iba1c3033c3c2f32de8e4a19b58d3921c971092c4
For future macro support, aapt2 must be able to convert Reference
values into other Value types. Currently a DescendingValueVisitor is
used to visit all of the References in a ResourceTable or a compiled
XML file to set their resource ids during the link phase. This was fine
since we were only mutating the resource id of the visited Reference.
A macro may reference a String, BinaryPrimitive, or any other Item
type. During the link phase, we will need to transform references to
macros into the values of the macros.
The only parameter in the methods of the ValueVisitor interface is a
raw pointer to the type being visited. The visitor interface does not
support reassigning the visited type to a different type.
ValueTransformer is a new interface for consuming a Value type and
transforming it into a compatible Value type. This change refactors
Value::Clone to use this interface.
Bug: 175616308
Test: aapt2_tests
Change-Id: Ic1b9d718b932c208764114cd9c74d880e189ccb0
For the SDK finalization changes, aapt2 must be able to handle
resources of the same type having different type ids. The
ResourceTable data structure currently stores package ids and type ids
on ResourceTablePackage and ResourceTableType respectively. This
prevents resource entries of the same type from having different type
ids without having to create another ResourceTableType structure.
JavaClassGenerator assumes each type only appears once in the
ResourceTable and it would need to dedupe the types to ensure one class
containing all the resource types ids is generated. TableFlattener on
the other hand needs a separate ResourceTableType for each type/id
combination so that the types are flattened into separate
ResTable_types.
This change simplifies aapt2's ResourceTable data structure:
- Resource ids are stored exclusively on ResourceEntry structures
meaning multiple entries can have different type ids while being
stored in the same ResourceTableType. Classes like JavaClassGenerator
can simply iterate over a type to see all the resources of the type
regardless of what their type id is.
- ResourceTable::GetPartitionedView() retrieves a list of resources
sorted and partitioned by package id, type id, and entry id. Classes
like TableFlattener can use this view to get separate
ResourceTavleTypes for each different type id that a type has.
These changes will also make it easy to have a resource span multiple
type ids if it exhausts all of the entry ids in one type id.
The new NewResourcesBuilder replaces the numerous setter methods on
ResourceTable.
Bug: 183102797
Test: aapt2_tests
Change-Id: I60dbcb24143bb958333899cafa7d41faa226d203
Update language to comply with Android's inclusive language guidance
See https://source.android.com/setup/contribute/respectful-code
for reference
Bug: 162364131
Bug: 162536543
Test: aapt2_tests
Change-Id: I4eef925d6319b40a395fc8d59a3f2912a02ca03b
For normal app development, the desired linking semantics are:
* styleables - take union of all definitions
* all other resources - take last non-weak definition
This differs from the semantics needed in other scenarios, where
merging/overlaying styles is desired.
Bug: 134525082
Change-Id: Iac0c43ca2ecf1f3fddc9c3367f8914c12c9258e1
Tested: aapt2_tests
If a resource is redefined with the same overlayable name, actor, and
policies, do not error.
Bug: 128843658
Test: m -j Launcher3 && aapt2_tests
Change-Id: I2c79f7d9fa7ff16b38ec41cec7e9804d39b372d5
Add a tracing API and instrument key functions in order to profile
aapt2 bottleneck. The API allows to generate systrace fragment files.
Impact on performance is neglibible with each Trace requiring less
than 1us and the final Flush operation at the end of a command
requiring around 40us.
Bug: None
Test: None
Change-Id: I51b564d3694e9384679f43b878b32295527dddf6
Add parsing of two overlayable attributes:
name : The unnique identifying name of the overlayable set of resources
actor: The component responsible for enabling and disabling overlays
targeting the specified set of resources
Bug: 110869880
Bug: 119390855
Test: m -j aapt2_tests
Change-Id: Id42463e2b92b69034fb39cd29bc8606affb61ba7
This change removes the ability for an overlayable resource to be
defined in multiple policy blocks within the same overlayable. This
change also changes aapt2 to use a bit mask to keep track of the parsed
policies.
Bug: 110869880
Bug: 120298168
Test: aapt2_tests
Change-Id: Ie26cd913f94a16c0b312f222bccfa48f62feceaa
<overlayable> tags can now have policy elements that indicate which
partition the overlay apk must reside on in order to be allowed to
overlay a resource. This change only adds parsing of <policy> and
encoding of policy in the proto ResourceTable. A later change will add
the encoding of policy and overlayable in the binary APK.
<overlayable>
<policy type="system|vendor|product|product_services|public" >
<item type="string" name="oof" />
</policy>
</overlayable>
Bug: 110869880
Test: make aapt2_tests
Change-Id: I8d4ed7b0e01f981149c6e3190af1681073b79b03
Always take the original comment of a resource. Resources passed in
through regular file arguments and resources added using the -R and
--auto-add-overlay flags will keep the same comments when overlayed by
another resource.
This will allow R.java files to remain consistent across devices between
product overlays.
Bug: 70641212
Test: aapt2_tests
Change-Id: I4ed1037a8d42f7e77d85e5c2a8ee78051053831a
Will only detect whether a resource was defined as both 'public' and
'private' (but will allow overriding 'undefined' visiblity for now).
Test: TableMerger_test + manual
Bug: 72735798
Change-Id: If0749559c91c4d8820a6286fc9ddc80209c1e5e9
Resources can be marked as overlayable, which means they can
be overlaid by runtime resource overlays.
This change propagates this state to the final resource table that
is installed on device.
Future work:
- Have the idmap tool respect the overlayable state and ignore
entries that overlay anything else.
Bug: 64980941
Test: make aapt2_tests
Change-Id: Id45b1e141a281be2ee32a4ac3096fcf1114d523b
This command allows a developer to convert their proto APK
(generated from the link phase using --proto-format) into
a binary APK suitable for use on device.
aapt2 convert -o output.apk input.apk
Test: manual + make aapt2_tests
Change-Id: I10a7c33bb4b57006d01fe00a8bf92f78e04e7e50
AAPT Container Format (.apc) is a simple container that
enumerates the various intermediate files that AAPT2 generates
during the compile phase.
The format is defined in formats.md.
For now, continue using the .flat extension for the container file,
and keep making use of the .flata zip for storing multiple files.
This will allow easier integration with existing build systems and allow
the evolution of the APC format to better handle arbitrarily large
files.
Test: make aapt2_tests
Change-Id: Id7216e5b76316bdd683f0fa4eaf2d2da273ba815
A few pieces were missing in the namespace mangling implementation.
Namespace aware libraries now work, along with R class generation.
Bug: 64706588
Test: make AaptTestNamespace_App
Change-Id: I12f78d6aa909e782c0faf7ceaa36058f2e6c864a
Previously style overlays would completely override an existing style.
To be compatible with AAPT, styles now merge with the overlay, allowing
the overlay's attributes and parent to take precedence.
Bug: 38355988
Test: make aapt2_tests
Change-Id: Id25c7240050a43e6a4a177c6e3d51e048d0cceb5
libandroidfw needs to make use of StringPiece, so
move it to libandroidfw and update all code referencing
StringPiece in aapt2.
Test: make libandroidfw_tests libaapt2_tests
Change-Id: I68d7f0fc7c651b048d9d1f5e7971f10ef5349fa1
Use Google3 naming style to match new
projects' and open source google projects' style.
Preferred to do this in a massive CL so as to avoid
style inconsistencies that plague legacy code bases.
This is a relatively NEW code base, may as well keep
it up to date.
Test: name/style refactor - existing tests pass
Change-Id: Ie80ecb78d46ec53efdfca2336bb57d96cbb7fb87
A compiled ResourceTable may contain multiple packages.
When referencing a framework attribute, for instance,
the compile phase has no idea if that attribute is a USE
or a DECLARATION, like so:
<declare-styleable name="Foo">
<item name="android:id" />
</declare-styleable>
If this file is compiled with the package 'android', then this
is a declaration. If it is compiled with the package 'com.foo',
this is a reference that must resolve at link time.
Since this is common, warning that the package 'android' is being
ignored during the merge phase is incorrect behaviour.
The warning was antroduced in ag/1363992
Change-Id: I09254d79ac379439face177eb724df882d1d0ce1
Styleables should only be merged when processing overlays.
This moves the styleable merging code out of ResourceTable
and into TableMerger.
Change-Id: I3aae05cf4dd875cd25ac2ac744b61194409b2fee
* Add explicit keyword to conversion constructors.
* Add NOLINT(implicit) comments for implicit conversion constructors.
Bug: 28341362
* Use const reference type for read-only parameters.
Bug: 30407689
* Use const reference type to avoid unnecessary copy.
Bug: 30413862
Test: build with WITH_TIDY=1
Change-Id: Id6d21961f313a1ad92b15a37fdaa5be9e8ab48e1
By the looks of things, AAPT2 should be able to merge public type and entry
symbols iff their types and resource IDs match.
Change-Id: Ie99071418aa89aad56de5e5b96e98b96d0d15d7a
For legacy reasons, we kept around the use of UTF-16 internally
in AAPT2. We don't need this and this CL removes all instances of
std::u16string and StringPiece16. The only places still needed
are when interacting with the ResTable APIs that only operate in
UTF16.
Change-Id: I492475b84bb9014fa13bf992cff447ee7a5fe588
Android static libraries are like APKs but they contain much more debugging
and source information. We need to treat them differently in 3 ways:
1) When building a static library, we skip things like ID assignment and
product/config stripping. Source information is emitted as well.
2) When building a static library and linking against another
static library, we don't want to merge, we want to simply reference.
3) When building an app that uses static libraries, we want to merge
the static library under the same package with or without mangling.
Bug:25958912
Change-Id: I425e032857936a3e83173c1edc2a6cdc6020b842
When a preferred density is supplied, the closest matching densities
will be selected, the rest stripped from the APK.
Split support will be enabled in a later CL. Command line support is still
needed, but the foundation is ready.
Bug:25958912
Change-Id: I56d599806b4ec4ffa24e17aad48d47130ca05c08
This allows us to preserve the various product definitions during the compile
phase, and allows us to select the product in the link phase.
This allows compiled files to remain product-independent, so that they do not need
to be recompiled when switching targets.
Bug:25958912
Change-Id: Iaa7eed25c834b67a39cdc9be43613e8b5ab6cdd7
Supports the <add-resource> tag and mimics old AAPT behavior of
not allowing new resources defined unless <add-resource> was used
or --auto-add-overlay was specified.
Change-Id: I9b461137357617ade37fd7045b418b8e6450b9c4
Merging local app resources is slightly different than merging
resources from a static library.
Local app resources may not have a package name set, but we do take interest in the
ID set for the package (should be 0x0 or match the ID of the app we're building).
Static library resources have an explicit package name defined for them, so we
only merge resources from that package.
Change-Id: I95e559ae94cc1df6972e77a347b1b37a93674c4d
Comments weren't being copied when merged from the various
resource tables.
Also refactored the JavaClassGenerator to omit a class
if no entries exist for it.
Change-Id: I6eaa89b7b3715bc05403635a2baf0d1db3efd142
Values are closely related to where they were defined, so
this information should live inside the Value.
This also enables comments to be attached to nested Values.
Change-Id: Ic7481b5a5f26d0ef248d638e2e29252f88154581
Need to introduce the idea of multiple levels of visibility to support <java-symbol>.
Public, Private, Undefined.
Public means it is accessible from outside and requires an ID assigned.
Private means that we explicitly want this to be a symbol (show up in R.java), but not visible
to other packages. No ID required.
Undefined is any normal resource. When --private-symbols is specified in the link phase,
these resources will not show up in R.java.
Change-Id: Icba89221e08e685dee7683786aa7112baf28c856
Unfortunately there is no good way to deal with products in the link phase.
Products are like preprocessor defines in that they are processed early
and change the composition of the compiled unit.
Change-Id: I6d5e15ef60d29df8e83e059ba857c09333993779
An early refactor. Some ideas became clearer as
development continued. Now the various phases are much
clearer and more easily reusable.
Also added a ton of tests!
Change-Id: Ic8f0a70c8222370352e63533b329c40457c0903e
