| 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
/frameworks/base/tests/SharedLibrary/lib/src/com/google/android/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
/frameworks/base/tests/SharedLibrary/lib/src/com/google/android/test/shared_library/ActivityMain.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
/frameworks/base/tests/SharedLibrary/lib/src/com/google/android/test/shared_library/ActivityMain.java
|