If the component being checked has been removed an NPE will be
thrown. This checks for that situation and handles it.
Fixes bug 14562234.
Change-Id: Ica5713378f356ac8441862d455b7d284ea111212
Once a Surface has been established the activity in an ActivityView
must be paused and resumed as the view goes in and out of visibility
= View.GONE.
Fixes bug 14034658.
Change-Id: Icab43678053c225db70f051dceacd4d024df2153
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
The ActivityView.startActivity method may defer calling
ActivityContainer.startActivity if the ActivityView is not yet
visible. If the activity being started doesn't have allowEmbedded
attribute set to true then the SecurityException will not be
thrown until the ActivityView is visible. In such a case the caller
of ActivityView.startActivity cannot catch the SecurityException.
This fix checks the attribute at the time ActivityView.startActivity
is called.
Fixes bug 14317210.
Change-Id: I7fff23e39b67a9a0aa1b2e555920d02ae38906d9
WallpaperManager should always do a null check on the service object.
SystemServer should always bring up the DevicePolicyManagerService,
and let the service do appropriate default no-ops if the feature
is not supported.
Change-Id: Iaaf12b60ed375fe2e341ec11faa10c9344d7d9da
