summaryrefslogtreecommitdiffstats
path: root/tests/SharedLibrary/client/res
diff options
context:
space:
mode:
authorDianne Hackborn <hackbod@google.com>2013-03-11 17:48:43 -0700
committerDianne Hackborn <hackbod@google.com>2013-03-12 12:51:38 -0700
commitc895be7bc68b6f5b37fbb9881f464dd5ea0eb017 (patch)
treefe7ba171c41d3df63b595adaf46a67ace2a7d7d3 /tests/SharedLibrary/client/res
parent9725d80adc7426ea20f3a193fc81dc1e8b8c4b31 (diff)
downloadframeworks_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.xml19
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>