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
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
To make S finalization easier, this changes the framework SDK so that
apps linking against it will be able to continue working as expected
after the first phase of SDK finalization.
During the first phase of SDK finalization, the resource ids of
resources that have not been removed are finalized.
staging-public-group tags are converted to staging-public-group-final
tags in order to encode into the framework what the staged resource id
of a finalized resource was. When an app recompiles, it will use the
finalized resource id. Then after all apps recompile, phase 2 of
finalization begins, in which the staging-public-group-final tags are
removed so apps can no longer use the staged resource ids.
Apps that link against the SDK (provided they are using a recent
version of aapt) will encode references to staged resources as
TYPE_DYNAMIC_REFERENCE and TYPE_DYNAMIC_ATTRIBUTE. The values of R
fields for staged resources are defined out-of-line to prevent them
from being inlined into apps linking agsint the SDK. This allows the
resource ids to change during phase 1 of API finalization.
Bug: 183413192
Test: `aapt2 diff` and resource ids stayed the same
Test: `aapt2 dump` of framework-res.apk and observe staged resources
Change-Id: Ie2275c608297a5f63dde8b1cf795415112cbcc24
staging-public-group is a tag for putting resources that have been
added during platform development, but have not yet been finalized,
into a separate resource id namespace.
R.java fields of staged resources are non-final, so when the SDK is
finalized, applications using the android R.java will automatically
use the new finalized resource id without having to recompile.
Staged resources can exist either in the same type id as the type's
non-staged counterpart or in a separate type id. Multiple
staging-public-group tags each with a different type id can exist
simultaneously, which allows for multiple versions of the platform
to be developed at once.
Bug: 183411093
Test: aapt2_tests
Change-Id: Ibb6c84c3626751e33c6097f35a03e306bb85616a
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
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
If a shared library exposes an attribute and a client uses the
attribute in its own styleable, the value of the lib attribute
resource id in the client styleable must be fixed with the correct
package id at runtime. Since the client will not have an
onResourcesLoaded to call, the client should directly reference the
attribute resource field in its styleable.
Bug: 147674078
Test: aapt2_tests
Change-Id: I8e64bb2d3165a7072e2604fe1730b248545978f4
I'm trying to enable a check for the following structure:
```
/** @hide */
public class Class1 {
/** @hide */
@SystemApi // Invalid because the class is hidden.
public void method1() { }
}
```
The internal R.java file violates this, which this change is going to fix.
Bug: 159162473
Test: build (treehugger)
Test: atest aapt2_tests
Change-Id: I613e8611ddaf5f8e4761d351d4cd0142d59c7cc9
SystemAPI can now be parameterized. Note that this change preserves
the content of the annotation params without attempting to interpret
them in any way. This means that references to types outside of
java.lang must be fully qualified.
Test: atest aapt2_tests
Bug: 147581540
Change-Id: I0630fb1c7c7a7f5918ff2dca32fb8e078b367751
We should keep classes that are in the android:name or class xml
attributes.
Test: m -j aapt2_tests
Bug: 142601969
Change-Id: Ia67365bd702bae75d38b9572d68e9930e856e0f8
Previous refactor accidentally assumed all attributes would have
resolvable symbols when generating the R class. Restore previous
behavior of calling SkipSymbol before retrieving the attribute
comment.
Bug: 145685954
Test: m TeleService
Change-Id: Ie8e1092556bc0b6a764462ffa0b99a876bcbd70e
R8 has some O(n^3) analysis somewhere, so this should speed up analysis
of "onResourcesLoaded" by 1.5^3=3.3x.
Bug: 145052564
Change-Id: Ib6ab111511d6bd3afae0c29cd00f743e7128768a
Tested: aapt2_tests
The results of CollectLocations() are only used if the --proguard-conditional-keep-rules option is set, but the function is always called when the --proguard option is set.
Since this function can be slow on particularly large resource sets, avoid calling it unless --proguard-conditional-keep-rules is set.
Change-Id: If259d41cdab16abad8ca62f30d8beb5ebf33575a
Bug: 144236322
Test: aapt2_tests
std::set only works correctly when the < comparator is a strict weak
ordering, while UsageLocation::operator< was actually implementing !=.
Bug: 134190468
Change-Id: Icb9407e9c8451f9fcb4eb9b2cea310e3bcaf159e
Tested: aapt2_tests, and b/134190468#comment1
(cherry picked from commit 44fa342eb9)
Apps commonly use the versions of the attributes from AndroidX, which
will be unqualified.
Bug: 30888677
Change-Id: Id7cb32b28edb1cd1b8113a8c9a7ee29107a1b67e
Tested: aapt2_tests
std::set only works correctly when the < comparator is a strict weak
ordering, while UsageLocation::operator< was actually implementing !=.
Bug: 134190468
Change-Id: Icb9407e9c8451f9fcb4eb9b2cea310e3bcaf159e
Tested: aapt2_tests, and b/134190468#comment1
* Add explicit to conversion constructors/operators
* Use NOLINT or NOLINTNEXTLINE to suppress warnings on intended converters
Bug: 28341362
Test: make with WITH_TIDY=1 DEFAULT_GLOBAL_TIDY_CHECKS=-*,google-explicit-constructor
Change-Id: Ie02101ea7c422e8add535c111a30a2f21ead0ace
AAPT2 generates documentation for styleables. The documentation contains
references to the attributes of the styleable. If the attributes are
marked @hide, remove the references to the attributes in the generated
coments.
Bug: 120262117
Test: m -j offline-sdk-docs
Change-Id: I541002077b17771d89caead04df2f4ae66c623f0
This is to allow idmap2 to access ConfigDescription.
Test: libandroidfw_tests
Test: aapt2_tests
Change-Id: I54210bbbd8dad5903cb7100807df977efa394ad5
Merged-In: I54210bbbd8dad5903cb7100807df977efa394ad5
We previously changed AAPT2 to correctly only generate keep rules for
the constructors required to inflate the different views. This cause
projects that did not have keep rules for the other constructors that
were accessed through reflection to have runtime crashes. This change
adds a flag to the link stage (--proguard-minimal-keep-rules) that
allows AAPT2 to only keep the constructors required for layout
inflation. If the flag is not present, then AAPT2 will generate less
specific keep rules than keep all constructors.
Bug: 116201243
Test: aapt2_tests
Change-Id: I8bb5cdf8446518ab153ea988e1243ca9494258c7
Bug: http://b/91353691
After assigning the result of TransformToFieldName to 'result', the
underlying storage is destroyed after the 'if' statement of the function
call. 'result' ends up with garbage if the identifier has a '-'.
ManifestClassGeneratorTest.NormalizePermissionNames is broken for this
reason in 32-bit Windows when using libc++ and 32-bit Linux. ASAN also
reports this failure for both 32-bit and 64-bit linux.
Test: Run test on the cases mentioned above and ensure all of them pass.
Change-Id: I69163c423c1171b7ac7838f2abe06bdf8058df4c
This expands the Context+AttributeSet constructor specificity from only work on <view class=> nodes to <my.Type> nodes.
Bug: 37123156
Test: make aapt2_tests
Change-Id: I8fb950731383f86bee225333bda27baf5a7a34c5
- For transition and pathMotion attributes the method must have Context and AttributeSet parameters.
- For actionViewClass and actionProviderClass attributes the constructor must have a single Context parameter.
- For Fragment's class or name attributes the constructor must have zero parameters.
Bug: 37123156
Test: make aapt2_tests
Change-Id: I34017abd182867ba95172835051d114cb2f3b3ac
This attribute was added in API 28 and is reflectively instantiated from a zero-argument constructor.
Test: make aapt2_tests
Change-Id: Ie9de0764165c6fe6c6fcda6cc38b0cc633f03bbd
When generating the R.java file, attributes of styleables do not always
have package names on them. This caused a problem where when an apk
that was previously linked and that also contained a declare-styleable
is linked again to an AndroidManifest.xml with a different package name,
styleable attributes' resource symbols could not be looked up correctly.
This change does not rename the resources but makes sure that the java
generator finds the attribute symbols correctly.
Bug: 110877419
Test: Created a test in aapt2_tests and verified correct behavior of
repro example from bug
Change-Id: Ib99d84cbe44dadca86603bc610ad3f4e09e3fb11
For View's onClick attribute the method must have a single argument of type android.view.View. For a MenuItem's onClick attribute the method must have a single argument of type android.view.MenuItem. Since these rules match all types and any return type, matching by signature is the only available specificity that can be added.
Bug: 37123156
Test: make aapt2_tests
Change-Id: I4b82f5ef9e62a8ecffaab424e269df627825709e
Reflection-based instantiation of manifest-declared types is only done on the default (aka no-argument) constructor. While these types are unlikely to have alternate constructors (unlike the others listed in the bug), there's no reason to generate overly keep-y rules for them.
Bug: 37123156
Test: make aapt2_tests
Change-Id: Ic83a2671a54ea5dd558bfcacf033a60e9568ab8c
