| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
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
|
|
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
|
|
rvc-dev-plus-aosp am: 7c72b7f45e am: 780aeb116a am: 47d47a8ac5
Original change: https://googleplex-android-review.googlesource.com/c/platform/frameworks/base/+/11955280
Change-Id: I602f8515391d93daf1d538f965659dfdca62e550
|
|
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
|
|
This is a similar fix to
https://googleplex-android-review.git.corp.google.com/c/platform/frameworks/base/+/10109386
but deals with styleable attributes instead of style items.
Bug: 147674078
Test: JavaClassGeneratorTest.SortsDynamicAttributesAfterFrameworkAttributes
Change-Id: Ida6572cf07e2b5987e9d8941cf169a37c43578c4
|
|
|
|
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
|
|
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
|
|
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
|
|
If we don't specifiy an output for R.java, don't try to write
data to the class definition
Change-Id: I3ad471ec93dcb8baf13f221174065679cce311ad
Fixes: 72547268
Test: out/host/linux-x86/nativetest64/aapt2_tests/aapt2_tests
|
|
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
|
|
Bug: 69956357
Test: manual
Change-Id: If2bc32bd4efb1ea17c6cba7a17f2b2300164ede0
|
|
FileOutputStream is safe to use on Windows, as it opens
files using our compatibility API.
Bug: 68262818
Test: make aapt2_tests
Change-Id: Ib0b27e93edd609b49b1327db7d9867a002198ebb
|
|
Test: make aapt2_tests
Change-Id: I7778b773201381538dc1f2e376abee4eb33e44c0
|
|
Add the option to produce keep rules that conditional keep based on
usage of R identifiers. This allows Proguard to potentially shrink more
code if resources are not used.
Currently only produces conditional rules for classes referenced in
layout resources because they are the most common and has the easiest
transitive usage chain to analyze.
Bug: 63628451
Test: make aapt2_tests and manual testing
Change-Id: I6c1af7affd64af40c80e004d8506a9463444b2c3
|
|
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
|
|
The old algorithm for detecting the first sentence of a JavaDoc comment
looked for the first occurence of '.'. This does not work when code or a
{@link android.R.styleable} link is encountered in the first sentence.
Switch to checking for whitespace characters after the '.' character.
Bug: 62900335
Test: make aapt2_tests
Change-Id: I8238f6a6304c9c2f92e2e576ca8962a59c2b20ea
|
|
The entire View code base checks IDs against View.NO_ID except
findViewById(), which checks to see if the ID is negative.
Any package ID > 0x7f is interpreted as a negative number in Java
(no unsigned ints), so this check prevents the use of IDs > 0x7f.
findViewById is final, so support library workarounds are not possible.
Instead, IDs (@id/foo) are just sentinels, their values don't matter.
If building for pre-O devices, rewrite any references to these IDs of
the for 0xPPTTEEEE, where PP > 7f, to 0x7fPPEEEE.
The symbol table will check for potential collisions against the base
APK, so this should be safe.
Bug: 37498913
Test: manual
Change-Id: Ife3bbd29db287757ef8a2ffd83053d97f1db2613
|
|
In order to support a staged rollout of support for AAPT2,
libraries being built the old way (merged into a single resource
directory) still need to make use of the generated R.txt AAPT
emitted. Do the same as AAPT.
Test: manual
Change-Id: Iaac1e824ddbd67e4efbab7692cddc1e4aa052f5a
|
|
Test: manual (building shared support library demo)
Change-Id: I4730645aa92ba1893baf67ffe35fbd4aac0f8e46
|
|
Test: make aapt2_tests
Change-Id: I98dddf1367e6c0ac425bb20be46e6ff05f4f2f45
|
|
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
|
|
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
|
|
We need the attributes to remain public because people might still be
linking against them, but we don't want them showing up in the
documentation any more. Them showing up in the documentation also had
the side effect that it would accidentally mark the parent class of
attributes as @removed, which was not intended.
Bug: 28663748
Change-Id: I2f6eb09455fddf1086e6b24bc3bea5292e8e32b7
|
|
- Don't generate private attributes in public R.java
- Strip out @SystemApi from comment when generating @android.annotation.SystemApi
- Only emit a single line (up to the first period) of an attribute's comment within
a styleable's attribute table.
Change-Id: Id6316a6861540325934133958939a12074ad4428
|
|
Mingw32 4.8 is kind of picky with macros and some complicated template
stuff. Luckily there was another way to represent the
SFINAE code that works on all platforms. Yay!
Change-Id: Idc2e38f47bfdc57b394550bfa0f53cc0b825df25
|
|
Change-Id: I7ee8c20cdd91380927a65c41097ffd3a6ffa2df5
|
|
Previously we would be writing out the Manifest.java file as we
processed the AndroidManifest.xml. This would lead to empty
Manifest classes if there were no permissions or permission groups
defined in the AndroidManifest.xml.
This would pose problems for processes that checked for public classes
and considered them part of the API (support lib).
Now we collect the structure of the Java class in memory before deciding
if a file should be created.
Change-Id: I6b909f28d74356414c6ef5ad005180d6ea5e44ca
|
|
Change-Id: I69e7b73cbdfe4baf502348397435c501ae29ff5e
|
|
Bug:25958912
Change-Id: I663f2eb5bd54e3c3288ce9bc186c928f0a014f93
|
|
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
|
|
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
|
|
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
|
|
Change-Id: Iaa5f3b75bf7de9dbf458fa5c452f7312989f4c4f
|
|
This includes comments from AndroidManifest.xml.
Change-Id: I412d9ecb12bad20a49a683d6b3bea4a0be1235ae
|
