3 Commits

Author SHA1 Message Date
Adam Powell
908c748096 Revert "Fix issue with using locally defined attrs in a shared lib"
This reverts commit 5069dd69898bd0d9c69ba2bbd37239ec8d1c9dc6.

The reverted commit caused issues loading resources supplied by static libraries.

Bug 17748356

Change-Id: I860a4f31451ee7c03c02974826472a67226b029f
2014-10-01 18:11:18 +00:00
Adam Lesinski
5069dd6989 Fix issue with using locally defined attrs in a shared lib
The attribute name resource IDs were never fixed up with
the runtime package ID so we weren't finding attributes
whenever the runtime package ID was different than the build
time one, which happened to be when a shared lib referenced itself
(0x00 vs 0x02).

Bug:17666947
Change-Id: Icf3e874bcea0e27eebe42d60fbed626a34bf9266
2014-09-30 16:18:09 -07:00
Adam Lesinski
de898ff429 Shared library resource support
Shared libraries can now export resources for applications
to use.

Exporting resources works the same way the framework exports
resources, by defining the public symbols in res/values/public.xml.

Building a shared library requires aapt to be invoked with the
--shared-lib option. Shared libraries will be assigned a package
ID of 0x00 at build-time. At runtime, all loaded shared libraries
will be assigned a new package ID.

Currently, shared libraries should not import other shared libraries,
as those dependencies will not be loaded at runtime.

At runtime, reflection is used to update the package ID of resource
symbols in the shared library's R class file. The package name of
the R class file is assumed to be the same as the shared library's
package name declared in its manifest. This will be customizable in
a future commit.

See /tests/SharedLibrary/ for examples of a shared library and its
client.

Bug:12724178
Change-Id: I60c0cb8ab87849f8f8a1a13431562fe8603020a7
2014-03-25 12:09:56 -07:00