History log of /frameworks/base/tests/SharedLibrary/lib/src/com/google/android/test/shared_library/SharedLibraryMain.java
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
ce5abb0a5542a0dae00a2af3b174d83cdd85a21f 15-Mar-2013 Dianne Hackborn <hackbod@google.com> Improve/flesh-out shared library version check.

Change-Id: I3d6eb19c8aeaae07a6d17de81ac707c7741608fb
/frameworks/base/tests/SharedLibrary/lib/src/com/google/android/test/shared_library/SharedLibraryMain.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/SharedLibraryMain.java