diff options
author | Dianne Hackborn <hackbod@google.com> | 2013-03-11 17:48:43 -0700 |
---|---|---|
committer | Dianne Hackborn <hackbod@google.com> | 2013-03-12 12:51:38 -0700 |
commit | c895be7bc68b6f5b37fbb9881f464dd5ea0eb017 (patch) | |
tree | fe7ba171c41d3df63b595adaf46a67ace2a7d7d3 /tests/SharedLibrary/client/res | |
parent | 9725d80adc7426ea20f3a193fc81dc1e8b8c4b31 (diff) | |
download | frameworks_base-c895be7bc68b6f5b37fbb9881f464dd5ea0eb017.zip frameworks_base-c895be7bc68b6f5b37fbb9881f464dd5ea0eb017.tar.gz frameworks_base-c895be7bc68b6f5b37fbb9881f464dd5ea0eb017.tar.bz2 |
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
Diffstat (limited to 'tests/SharedLibrary/client/res')
-rw-r--r-- | tests/SharedLibrary/client/res/values/strings.xml | 19 |
1 files changed, 19 insertions, 0 deletions
diff --git a/tests/SharedLibrary/client/res/values/strings.xml b/tests/SharedLibrary/client/res/values/strings.xml new file mode 100644 index 0000000..3757a25 --- /dev/null +++ b/tests/SharedLibrary/client/res/values/strings.xml @@ -0,0 +1,19 @@ +<?xml version="1.0" encoding="utf-8"?> +<!-- Copyright (C) 2013 The Android Open Source Project + + Licensed under the Apache License, Version 2.0 (the "License"); + you may not use this file except in compliance with the License. + You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. +--> + +<resources> + <string name="app_title">SharedLibrary client</string> +</resources> |