| 908c748096d855d47da2f5e20fd4d9d31d1e603c |
01-Oct-2014 |
Adam Powell <adamp@google.com> |
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
ndroid/test/shared_library/ActivityMain.java
|
| 5069dd69898bd0d9c69ba2bbd37239ec8d1c9dc6 |
01-Oct-2014 |
Adam Lesinski <adamlesinski@google.com> |
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
ndroid/test/shared_library/ActivityMain.java
|
| de898ff42912bd7ca1bfb099cd439562496765a4 |
30-Jan-2014 |
Adam Lesinski <adamlesinski@google.com> |
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
ndroid/test/shared_library/AddressView.java
|
| ce5abb0a5542a0dae00a2af3b174d83cdd85a21f |
15-Mar-2013 |
Dianne Hackborn <hackbod@google.com> |
Improve/flesh-out shared library version check.
Change-Id: I3d6eb19c8aeaae07a6d17de81ac707c7741608fb
ndroid/test/shared_library/SharedLibraryMain.java
ndroid/test/shared_library/VersionDialog.java
|
| c895be7bc68b6f5b37fbb9881f464dd5ea0eb017 |
12-Mar-2013 |
Dianne Hackborn <hackbod@google.com> |
Implement limited shared libraries in apks.
You can now declare shared libraries in apks that are
on the system image. This is like the existing mechanism
of using raw jar files as shared libraries, but since they
are contained in an apk the library can actually be updated
from the Play Store. And this even (mostly) works.
There are some deliberate limitations on this feature. A
new shared library *must* be declared by an apk on the system
image. Installing an update to a system image apk does not
allow you to add new shared libraries; they must be defined
by everything on the base system image. This allows us to
get rid of a lot of ugly edge cases (shared libraries that were
there disappearing after an update is uninstalled for example)
and give some brakes on apps that happen to be pre-installed
on devices from being able to throw in new shared libraries
after the fact.
In working on this, I ran into a recently introduced bug where
uninstalling updated to system apps would fail. This was done
to allow for the new restricted users that don't have all
system apps, but conflicts with the existing semantics for
uninstalling system apps. To fix this I added a new uninstall
flag that lets you switch on the new mode if desired.
Also to implement the desired logic for limitations on declaring
new shared libraries in app updates, I needed to slightly tweak
the initial boot to keep the Package object for hidden system
packages associated with their PackageSetting, so we can look at
it to determine which shared libraries are allowed. I think
this is probably more right than it was before -- we already
need to parse the package anyway, so we have it, and when you
install an update to a system app we are in this same state
until you reboot anyway.
And having this fixed also allowed me to fix another bug where
we wouldn't grant a new permission to an updated app if its
system image version is updated to request the permission but
its version is still older than whatever is currently installed
as an update. So that's good.
Also add new sample code showing the implementation of an apk
shared library and a client app using it.
Change-Id: I8ccca8f3c3bffd036c5968e22bd7f8a73e69be22
ndroid/test/shared_library/ActivityMain.java
ndroid/test/shared_library/SharedLibraryMain.java
|