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
