As per a comment on an earlier code review.
(cherry-picked from commit a9d64733421d6765eab5c2730fa912f068e26047)
Change-Id: I064cffc13c323b721f3a16c83e0e95ee348ef9f6
If means the package hasn't been scanned yet, and we
will adjust the ABI during the scan of the last package
in the shared user group.
NOTE: This needs some more cleaning up, which will be
done along with the remaining TODO in this function.
(cherry picked from commit 6609990e35b11c38f55f6e632160d4f2ff201ea3)
Change-Id: Ibace7849485865054e062d2b979f320bf89ff0f3
We should now prune all normal files from /data/dalvik-cache
in addition to looking for dex files in all subdirectories of
/data/dalvik-cache.
(cherry picked from commit 51a6f9253399588eedf77d75c578d9aa23d11529)
Change-Id: I536dfdc48e94155e7be64eb4efd9f7f2a1d2d00a
Since shared UID apps are run in the same process,
we'll need to make sure they're compiled for the same
instruction set.
This change implements the recompilation of apps that
don't have any ABI constraints.
Apps that *do* have ABI constraints are harder to deal
with, since we'll need to rescan them to figure out the
full list of ABIs they support and then re-extract the
native libraries from these apps once we find an ABI we
can use throughout.
(cherry picked from commit 85703d58af1dac692d7d83c03220e45ab2a5aded)
Change-Id: I8311a683468488cc7e30381965487a3d391609ae
- Pass down the app's instruction set to dexopt so that
it can compile the dex file for the right architecture.
- Also pass down the app's instruction set to rmdex, movedex
and getSize so that they can construct the cache file
location properly.
- Temporarily compile "system" jars such as am,wm etc. for
both architectures. A follow up change will ensure that
they're compiled only for one architecture (the same
arch. as the system server).
- Java "shared" libraries are now compiled for the right
architecture when an app requires them.
- Improve the app native library ABI detection to account
for system apps installed in /system/lib{64}/<packagename>
and also handle sdcard and forward locked apps correctly.
(cherry-picked from commit b4d35dc8e9702f9d0d82d35a105f0eea35672b52)
The per-package /system/lib/* feature introduced bugs in the
native library path handling during app upgrade installs. The
crux of the fix is that when recalulating the desired native
library directory, the basis for the calculation needs to be
the scanned APK's location rather than the extant package
settings entry -- because that entry refers to the pre-upgrade
state of the application, not the new state.
Bug 14233983
(cherry picked from commit 353e39a973)
Change-Id: I26f17a596ca2cd7f963955c0642548c15138ae26
Bundled apps can now use /system/lib/apkname or /system/lib64/apkname
in addition to the (globally shared) /system/lib and /system/lib64
directories. Note that when an app is updated post hoc the update APK
will look to its normal library install directory in
/data/data/[packagename]/lib, so such updates must include *all*
needed libraries -- the private /system/lib/apkname dir will not be in
the path following such an update.
"apkname" here is the base name of the physical APK that holds the
package's code. For example, if a 32-bit package is resident on disk
as /system/priv-app/SettingsProvider.apk then its app-specific lib
directory will be /system/lib/SettingsProvider
Bug 13170859
(cherry picked from commit addfbdc09c)
Change-Id: Id82da78024a6325458b8b134d7d91ad0e5f0785e
This patch uses the NativeLibraryHelper class to
match native libraries in an .apk package with
those listed in 'ro.cpu.abilist' property.
The result is stored in packages.xml and the
ApplicationInfo class.
This information will be used by the ActivityManager
to decide which zygote to use to launch the given
app.
Change-Id: I3ec3d050996d8f4621f286ca331b9ad47ea26fa0
We now use a two step approach :
- First we look through the list of shared libraries in an
APK, and choose an ABI based on the (priority) list of ABIs
a given device supports.
- Then we look through the list of shared libraries and copy
all shared libraries that match the ABI we've selected.
This fixes a long-standing bug where we would sometimes copy
a mixture of different ABIs to the device, and also allows us
to clearly pick an ABI to run an app with.
The code in NativeLibraryHelper has been refactored so that all
file name validation & matching logic is done in a single place
(NativeLibrariesIterator). This allows us to avoid a lot of
redundant logic and straightens out a few corner cases (for eg.
where the abi determination & copying logic do not agree on
what files to skip).
bug: https://code.google.com/p/android/issues/detail?id=65053
bug: 13647418
Change-Id: I34d08353f24115b0f6b800a7eda3ac427fa25fef
Co-Authored-By: Zhenghua Wang <zhenghua.wang0923@gmail.com>
Co-Authored-By: Ramin Zaghi <ramin.zaghi@arm.com>
Co-Authored-By: Narayan Kamath <narayan@google.com>
Perform the relabel of the /data/data/<pkg> directories
when the app is being scanned by the PMS. The impetus
for this change was that the data directories of forward
locked apps were receiving the wrong label during an
OTA. Because the PMS doesn't actually scan forward locked
apps til later in the boot process, the prior restorecon
call was actually applying the default label of
system_data_file for all such apps. By performing a
restorecon on each individual app as they are entered into
the PMS we can handle them correctly. This mechanism also
allows us to pass down the seinfo tag as part of the
restorecon call which drops our need to rely on the contents
of packages.list.
Change-Id: Ie440cba2c96f0907458086348197e1506d31c1b6
Signed-off-by: rpcraig <rpcraig@tycho.ncsc.mil>
This change applies a relabel to both /data/data and
/data/user directories on boot. Not every boot will
apply this relabeling however. The appropriate
seapp_contexts is hashed and compared to
/data/system/seapp_hash to decide if the relabel
should occur.
Change-Id: I05e8b438950ddb908e46c9168ea6ee601e6d674f
Signed-off-by: rpcraig <rpcraig@tycho.ncsc.mil>
This is a change to add args to some of the profiler related
functions, including installd commands.
Also read properties and set command line options for the runtime
profiling parameters.
Changed calls to isDexOptNeeded() to isDexOptNeededInternal(). This
needs additional arguments passed for profiles.
Bug: 12877748
Change-Id: I1a426c9309d760bac0cf92daa298defee62287c1
Conflicts:
core/jni/AndroidRuntime.cpp
Fixes the case when the app on system is newer than the
currently installed. Something that can happen e.g. after
a FOTA update.
Change-Id: I102e9cdd5693d5e66667c0c8989dc2643c72dd16
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
It wasn't possible to start apps installed in /vendor/app
on a device where /vendor was a symbolic link to /system/vendor.
This is currently the default configuration for android (see
init.rc)
During installation a dex file is created at:
/data/dalvik-cache/vendor@app@blah.blah.apk@classes.dex
But dalvik would fail to start this app with the following error:
I/dalvikvm( 3453): Unable to open or create cache for /system/vendor/app/blah.apk \
(/data/dalvik-cache/system@vendor@app@blah.blah.apk@classes.dex)
Note that dalvik were trying to start /system/vendor/app while the
app was installed in /vendor. There was a conflict between the
package manager and dalvik on how to interpret paths. This change
makes the package manager consistent with dalvik.
Change-Id: I1c7e3c3ae45f97dd742cbf06f7965a7405c821a7
Since Kitkat, an app pre-loaded under /system/priv-app/ has
FLAG_PRIVILEGED. However, if the app updated and the device
rebooted, privileged flag is unset from pkgFlags. This patch
fix issue to assign privileged flag when scanning the updated
packages.
Bug: 12640283
Change-Id: Ic24b5882f65dabdfae9cc39da3d68661bed4fc31
User removal or eviction inherently races with broadcast delivery. This
patch introduces a latest-possible recheck of the availbility of the
target application before attempting to send it a broadcast.
Once the process has actually been spun up the system is essentially
committed to presenting it as a running application, and there is no
later check of the availability of the app: the failure mode for
continuing to attempt delivery is a crash *in the app process*,
and is user-visible.
We now check the app+userid existence of the intended recipient
just prior to committing to launch its process for receipt, and
if it is no longer available we simply skip that receiver and
continue normally.
Bug 11652784
Bug 11272019
Bug 8263020
Change-Id: Ib19ba2af493250890db7371c1a9f853772db1af0
Also use the existing full PreferredActivity match machinery instead
of the existing direct comparison now that the intent filters can
be more flexible.
Bug 11482259
Change-Id: Icb649ca60ecfbdb9ee3c256ee512d3f3f989e05f
In particular, if a 3rd party app tries to define a permission that
turns out to be defined by system packages following an upgrade,
the system package gets ownership and grants are re-evaluated
on that basis.
Bug 11242510
Change-Id: Id3a2b53d52750c629414cd8226e33e5e03dd0c54
We also now ignore attempts to set preferred resolutions with
intent filters for which no actions are defined.
Bug 11392870
Change-Id: If0d0b37bf01b59463985441edfc2bddd070bfc2a
We need to be able to perform very lengthy operations on some threads
(e.g. the I/O thread responsible for installing multi-gigabyte APKs) but
still have long-run deadlock/hang detection applied to those threads.
Previously the watchdog mechanism applied the same policy to all
monitored threads: unresponsive after 60 seconds => restart the system.
Now, each monitored entity can have its own independent timeout after
which the watchdog declares deadlock and restarts the runtime. The
halfway-finished intermediate thread stacks are dumped based on the
specific entity's declared timeout, not the global 30 second checking
interval.
With that new mechanism in place, the Package Manager's lengthy-I/O
thread watchdog timeout is raised to 10 minutes.
Bug 11278188
Change-Id: I512599260009c31416b2385f778681e5b9597f05
Because properly continuing permission grants post-OTA has changed
policy to include privilege considerations based on install location,
make sure that we re-evaluate when we determine that the apk has
moved from its pre-OTA location.
Bug 11271490
Change-Id: I6c09986e2851a67504268b289932588457c05dfc
In this case:
1. Privileged system app FOO is overlain by an installed update,
2. FOO was replaced during an OTA,
3. The new in-system FOO introduced new privileged permission requests
that had not been requested by the original FOO,
4. the update version of FOO still had a higher version code than
the new FOO on the system disk, and
5. the update version of FOO had been requesting these same (newly-
added-to-system-apk) permissions all along;
then the newly-added privileged permission requests were incorrectly being
refused. FOO should be able to use any privileged permission used by the
APK sited on the system disk; but instead, it was only being granted the
permissions used by the *original* version of FOO, even though the system
FOO now attempted to use them.
Still with me?
The fix is to (a) properly track privileged-install state when processing
known-to-be-hidden system packages, and (b) to tie the semantics of the
permission grant more explicitly to that evaluated state, rather than
using the prior (rather fragile) fixed-up privilege calculation applied
to the overlain apk's parse records.
Bug 11271490
Change-Id: Id8a45d667e52f3b5d18109e3620d5865f85bb9c9
For the new documents work, we're only interested in the subset of
ContentProviders that actually implement DocumentsContract. Instead
of returning all providers, add <intent-filter> support to make it
easier to limit the set of returned ProviderInfo.
Define a well-known action for DocumentsProviders, and start using it
when querying for roots. Continue supporting the old <meta-data>
approach until all apps have been updated.
Bug: 8599233
Change-Id: I05f049bba21311f5421738002f99ee214447c909
When reparsing because the data-volume update has been removed, be sure
to apply privilege when the bundled fallback APK should be allowed it.
Bug 10958159
Change-Id: Ibad52a5644606b27f4ebc5d5d7c1a671283b0752
When an apk is installed on ordinary unmountable media, a broadcast
is sent when the OS wants to unmount it so that interested parties
can cleanly close any files they have open to read that apk's
resources or similar. We now send that broadcast when we are
about to unmount the ASEC fs container that holds a forward-locked
apk as well, so that e.g. Home knows to release the resources that
it was using for widget hosting or similar.
Bug 7703848
Change-Id: I71aefdb4086c7b73a128f89c15d192a2b92d09a8
