AAPT2 Macros are compile-time resources definitions that are expanded
when referenced during the link phase.
A macro must be defined in the res/values.xml directory. A macro
definition for a macro named "foo" looks like the following:
<macro name="foo">contents</macro>
When "@macro/foo" is used in the res/values directory or in a compiled
XML file, the contents of the macro replace the macro reference and
then the substituted contents are compiled and linked. If the macro
contents reference xml namespaces from its original definition, the
namespaces of the original macro definition will be used to determine
which package is being referenced.
Macros can be used anywhere resources can be referenced using the
@package:type/entry syntax.
Macros are not included in the final resource table or the R.java since
they are not actual resources.
Bug: 175616308
Test: aapt2_tests
Change-Id: I48b29ab6564357b32b4b4e32bff7ef06036382bc
This changes refactors tests to use the NewResourceBuilder class
that makes it easier to construct resource entries.
Bug: 183102797
Test: aapt2_tests
Change-Id: I851f9fb99a003769f8df8c1876997eee0864822a
Add uses-split dependencies to AppInfo. At link time, this is used
and allows features to reference other features, before
resource namespacing is implemented in Android Studio.
bug:135681292
Test: Link_test, ReferenceLinker_test, and integration tests.
Change-Id: Ifdf0067e7370552b6b9d4d6d4713d4484b6ea154
This reverts commit 481f027ddc.
Reason for revert: Not needed any more
Bug: 111543815
Test: existing unit and integration tests
Change-Id: I87b039192682636d81c2d33512495cb005c9504d
Introduces a link flag --auto-namespace-static-lib for use when linking
static libraries.
When linking a static library with compiled sources that have references
to resources in provided libraries without an explicit package name,
the flag enables automatic inference of the package.
If a resource is present in the package that is being compiled, that is
used, otherwise the reference is rewritten to the highest precedence
resource with matching name and type.
Test: m out/host/linux-x86/nativetest64/aapt2_tests/aapt2_tests && \
$ANDROID_HOST_OUT/nativetest64/aapt2_tests/aapt2_tests
Test: m frameworks/base/tools/aapt2/integration-tests
Change-Id: I6c6017e054654d1f60782d0a428a7a2a47f8952b
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
Since the latest gtest has fixed support for
explicit bool operators, remvoe AAPT_ASSERT_* and AAPT_EXPECT_*.
Also switch to use NotNull() matchers, which are more legible.
Test: make aapt2_tests
Change-Id: Idce199ca9d567d70f7aae275fee15e04bb914c9e
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
Previously the way to name resources in tests was to use reference
notation (@[package:][type/]name). Now we use name notation (no @).
Change-Id: I68f0a36562d89cc78c582d128f370d9556c58707
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
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
