Add /system/priv-app and /oem/app paths to system paths. Also allow
rmdex on system apps, and quietly ignore when it was already removed.
Also relax logging when clearing code cache, since it's optional.
Bug: 17205122
Change-Id: I4fc4d0f63a3596937c4defbd64e1f8a1c563f02d
It should nuke everything under the data directory. PMS will come
around and generate the lib symlink after we're finished.
Bug: 16739202
Change-Id: Ib70af2e1450e3bed6781fb497b9cc67e1e594c49
System apps are now installed under their own directory
(system_app_dir/app_dir/app.apk). The new path doesn't pass installd
validation because of obsolete checks which verify that the path does
not contain subdirectories past the system_app_dir.
The CL fixes the validation to accept at most on subdirectory.
Bug: 17109858
Change-Id: I13abb52c0016610ff436f6a26bb6b3b85dc4dfb0
In the current directory layout this prevented rm_dex and move_dex
commands to validate the apk path and thus cleaning up resources.
Bug: 16888084
Change-Id: Iba579d075a9c6d7de047e7ffef95441498257086
This will allow us to conditionally change the compiler-filter based on other properties.
Bug: 15165413
(cherry picked from commit cf51ba1360)
Change-Id: I6613c9710878d56ed8c121e0caded76a64430f76
Make installd understand a patchoat directive and carry it out.
Bug: 15358152
(cherry picked from commit 7365a10689)
Change-Id: Id84a15e626ddde63876914068d3d9aa037abc65b
This requires a companion package manager change to prune
each instruction specific dex cache individually.
bug: 15677279
Change-Id: I5891981512bde20e49bff65b1842c28886f2b177
Profiling information leaks data about how people interact
with apps, so we don't want the data to be available
to other apps. Only the app and system_server need access.
Don't create the /data/dalvik-cache/profiles directory. init.rc
does it for us now.
Change-Id: Ic1b44009faa30d704855e97631006c4b990a4ad3
Add profile-file option to dex2oat only if the profiler is active and
the file exists.
Bug: 12877748
Bug: 15275634
Change-Id: Icef76514c912c88311ed108f2be7a6329131f741
With new CA certificates being stored in /data/misc/user/<userid>/
existing ones need to be moved into the same place.
After this update only the owner user will have custom trusted CAs; all
other users will revert to the default set.
Change-Id: I14a4cd6048685902ad5dd3b53494b03fadc41c04
New command 'mkuser <id>' sets up a user directory in /data/misc/user/,
readable by all apps within that user and writeable by the local system
process.
Change-Id: I5ddde8c4a80f606e723bb41aa64581a0720842d5
At present, the app lib symlinks are created before setting
the package directory security context, and therefore default
to system_data_file. Upon a later restorecon_recursive,
they are relabeled to the same type as the package directory,
e.g. app_data_file. Avoid this inconsistency by setting the
package directory security context before creating the symlink
so that it inherits the same security context.
Change-Id: I1ee6ccd8a2aa63a4d2efda67f313c97932235911
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
The instruction-set is used to construct the dalvik cache
path and is also passed down to dex2oat.
(cherry picked from commit 791781bfb8)
Change-Id: I43396b16f6eaecacf0fb7d052526fc5a239167ac
It's wrong to just concatenate the apk_path and .odex.
The bug prevents the prebuilt odex being used since Kitkat.
The patch is copied from the code of JellyBean.
Change-Id: I0ce8a877e3df8ae1ab9a0e3aeeef2d5253efc223
This is required so that it will be assigned the correct SELinux
security context on first creation by installd.
Bug: 13927667
Change-Id: I4857d031f9e7e60d48b8c72fcb22a81b3a2ebaaa
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Changes above with PMS and below with libselinux
have resulted in a few changes to the restorecon data
api. This change is needed in order to support the new
way to issue a recursive restorecon of certain
/data/data directories.
The restorecondata function has also been modified to
find all users on the device for a given package name
(argument to the function) and to issue a separate
recursive restorecon call for each.
Change-Id: Ie440cba2c96f0907458086348197e1506d31c1b6
Signed-off-by: rpcraig <rpcraig@tycho.ncsc.mil>
Otherwise we can't readily see log messages from libselinux calls
made by installd.
Change-Id: I319b30c181470468fe19dd5fbe9251ef03f1163b
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Implement new restorecondata function which will allow
the relabeling of /data/data and /data/user directories.
This is needed in the case of certain OTAs. Not every
boot will apply this relabeling however. Consult change
I77bf2a0c4c34b1feef6fdf4d6c3bd92dbf32f4a1 for
clarification on this issue.
Change-Id: I05e8b438950ddb908e46c9168ea6ee601e6d674f
Signed-off-by: rpcraig <rpcraig@tycho.ncsc.mil>
Add args to the installd commands for profiler usage.
Make installd create the profile files and allow apps
to write to them.
The profile files are in /data/dalvik-cache/profiles. This
central location is needed due to permissions issues with
dex2oat reading from an app's data directory. The solution
is to put the profile file in a directory owned by the
install user and make the file writeable by the shared group
id of for the app. The app can read and write to these files
only in the profiles directory. The 'system' user also needs
to be able to read the files in order to determine the amount
of change to the file over time.
Bug: 12877748
Change-Id: I9b8e59e3bd7df8a1bf60fa7ffd376a24ba0eb42f
Conflicts:
cmds/installd/commands.c
We would occassionally pass in an empty arg "" instead of a NULL.
This caused problems since dex2oat isn't made to handle empty args.
Change-Id: Ibb1aed64a4aa17459b2a75a5a2abcf13c7fa8ac7
installd project has moved from frameworks/base to frameworks/native
and so its test project's c_include path defined in Android.mk
has to match the change.
Change-Id: I597125ff659f51edbd9fc95371790e2d567c78be
libselinux selinux_android_restorecon API is changing to the more
general interface with flags and dropping the older variants.
Also get rid of the old, no longer used selinux_android_setfilecon API
and rename selinux_android_setfilecon2 to it as it is the only API in use.
Change-Id: I1e71ec398ccdc24cac4ec76f1b858d0f680f4925
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Support any number of overlay packages. Support any target package.
UPDATED PACKAGE MATCHING
------------------------
In Runtime resource overlay, iteration 1, only a single overlay package
was considered. Package matching was based on file paths:
/vendor/overlay/system/framework-res.apk corresponded to
/system/framework-res.apk. Introduce a more flexible matching scheme
where any package is an overlay package if its manifest includes
<overlay targetPackage="com.target.package"/>
For security reasons, an overlay package must fulfill certain criteria
to take effect: see below.
THE IDMAP TOOL AND IDMAP FILES
------------------------------
Idmap files are created by the 'idmap' binary; idmap files must be
present when loading packages. For the Android system, Zygote calls
'idmap' as part of the resource pre-loading. For application packages,
'idmap' is invoked via 'installd' during package installation (similar
to 'dexopt').
UPDATED FLOW
------------
The following is an outline of the start-up sequences for the Android
system and Android apps. Steps marked with '+' are introduced by this
commit.
Zygote initialization
Initial AssetManager object created
+ idmap --scan creates idmaps for overlays targeting 'android', \
stores list of overlays in /data/resource-cache/overlays.list
AssetManager caches framework-res.apk
+ AssetManager caches overlay packages listed in overlays.list
Android boot
New AssetManager's ResTable acquired
AssetManager re-uses cached framework-res.apk
+ AssetManager re-uses cached 'android' overlays (if any)
App boot
ActivityThread prepares AssetManager to load app.apk
+ ActivityThread prepares AssetManager to load app overlays (if any)
New AssetManager's ResTable acquired as per Android boot
SECURITY
--------
Overlay packages are required to be pre-loaded (in /vendor/overlay).
These packages are trusted by definition. A future iteration of runtime
resource overlay may add support for downloaded overlays, which would
likely require target and overlay signatures match for the overlay to
be trusted.
LOOKUP PRIORITY
---------------
During resource lookup, packages are sequentially queried to provide a
best match, given the constraints of the current configuration. If any
package provide a better match than what has been found so far, it
replaces the previous match. The target package is always queried last.
When loading a package with more than one overlay, the order in which
the overlays are added become significant if several packages overlay
the same resource.
Had downloaded overlays been supported, the install time could have been
used to determine the load order. Regardless, for pre-installed
overlays, the install time is randomly determined by the order in which
the Package Manager locates the packages during initial boot. To support
a well-defined order, pre-installed overlay packages are expected to
define an additional 'priority' attribute in their <overlay> tags:
<overlay targetPackage="com.target.package" priority="1234"/>
Pre-installed overlays are loaded in order of their priority attributes,
sorted in ascending order.
Assigning the same priority to several overlays targeting the same base
package leads to undefined behaviour. It is the responsibility of the
vendor to avoid this.
The following example shows the ResTable and PackageGroups after loading
an application and two overlays. The resource lookup framework will
query the packages in the order C, B, A.
+------+------+- -+------+------+
| 0x01 | | ... | | 0x7f |
+------+------+- -+------+------+
| |
"android" Target package A
|
Pre-installed overlay B (priority 1)
|
Pre-installed overlay C (priority 2)
Change-Id: If49c963149369b1957f7d2303b3dd27f669ed24e
