Bug 14443184
Also gave the propagation speed a tweak to make it more
obvious that there is a propagation.
Change-Id: If9dc3172ae6ce7e6a712ccd1b83ebec9bf880bfa
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 353e39a973dbbadce82fee2f83ad194e04a47449)
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 addfbdc09ccf258395db8bfc510989a4c583f7ab)
Change-Id: Id82da78024a6325458b8b134d7d91ad0e5f0785e
Partial cherry-pick of changes 4ca728c0 and 21de56a9, which
can't be cherry-picked due to their large surface area.
Change-Id: Ife46e150d360cd5241dea93863141749233c1805
