Check that each package from the setting has
a parsed pkg before we attempt to perform dex-opt
on it. If it doesn't have a parsed package, adjust
the ABI in the settings, but don't perform dexopt.
It will be dexopted later if it's still active
based on the setting.
bug: 15081286
Change-Id: Ifb6d1d5efdc9c59b251731972afa951ad930d05c
The key improvement is that we need to keep track of
the package that's currently being scanned (this includes
new installs and upgrades of existing packages) and treat
it specially. If we didn't do that, In the case of upgrades
we would perform the shared UID calculation based on the ABI
of the old package, and not the current package.
This change also allows us to perform the CPU ABI calculation
before dexopt, which saves us from having to do it twice and
fixes a bug where we were using the wrong package path to
dexopt a package.
This also has the side effect of fixing 15081286.
bug: 15081286
Change-Id: I20f8ad36941fc3df29007f0e83ce82f38f3585c8
It's not worth the complexity of rescanning the APK and
extracting a shared library with a different ABI.
Also gets rid of an unnecessary command line argument and
checks for dex-opt failures while adjusting shared ABIs.
bug: 14453227
Change-Id: I6a0695e24cba37e93540c540507088e95b89089b
This ensures it's the same size in both 32 and 64 bit
processes and also brings it in line with struct
MotionEntry.
(cherry-picked from commit bc6001b026069714177526eb1120b0011d6f2a51)
Change-Id: Ide6bb4dc05cc92a7ae8833e615e8ebb2353255a6
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 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
This change contains fixes to base from libcore change
I37de3e7d1a005a73821221e6156d10b95c595d7a
Bug: 13927110
Change-Id: I2d96e50307611c269dcf47886cd4d976854da8fc
This fixes a bug where a View with filterTouchesWhenObscured will have
all touches filtered when in magnification accessibility mode. This is
due to magnification being a separate Window over top of the running
Activity. The method onFilterTouchEventForSecurity in View will then
always return false when filterTouchesWhenObscured is enabled on the
View. By adding the magnification Window to the list of Trusted Overlays
we can ensure that touches will work properly with this property enabled.
Change-Id: I07706588a625682d05da5cb19f401139eb08a54c
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>
Symptom: ANR report on wrong activity.
Root Cause:
KK changed resume behavior that will not update focus when only resume,
if the activity blocked, it may report ANR on previous focus.
By original concept, it will try to correct the ANR target,
but the stack of waiting(waitingVisible=true) activity may
different with current top stack.
If it gets key dispatch timeout, mResumedActivity and mPausingActivity
of its stack will be null becuase it is not top stack.
Then it is unable to change ANR target to the real no response activity.
Solution:
Use focused stack to get the real culprit.
Reproduce steps:
1.Launch an Activity X from launcher, press home key.
2.Launch X from launcher again, X blocks(sleeps 15sec) in onResume, press back key in the beginning of blocking duration.
3.ANR dialog shows launcher is no response.
Change-Id: I99416ad91e349096f995990f2240a97616fbaf28
The Zygote class is now in com.android.internal.os. It is
responsible for the vast majority of work before and after
the call to fork(). It calls back into the Runtime via
the new dalvik.system.ZygoteHooks class to allow the Runtime
to perform pre fork cleanup and post fork initialization.
The native code in Zygote.cpp is a direct and straightforward
port of the existing code in art. Most differences are
superficial, for example :
- We use C style logging (ALOGE) instead of stream based
logging.
- We call env->FatalError() instead of using LOG(FATAL)
Change-Id: Ia101fb2af12d23894fe57e4134d2bc6d142e5059
This field is written and read exclusively by the system server,
and should therefore belong to the SystemServer class.
Change-Id: I2708a9a45c0c9cd1a6f563e8cc5844bd8c424bf7
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>
Changes in this patch include
[x] Use %zu for size_t, %zd for ssize_t
[x] Some minor changes have been done to conform with
standard JNI practice (e.g. use of jint instead of int
in JNI function prototypes)
Change-Id: Id1aaa7894a7d0b85ac7ecd7b2bfd8cc40374261f
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Craig Barber <craig.barber@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
When ensureActivitiesVisibleLocked goes through foreground activity
stack and reaches non-fullscreen activity, it sets showHomeBehindStack
variable to true.
If there is a fullscreen activity behind, showHomeBehindStack remains
unchanged, which causes Home application to be displayed anyway.
In this case user will see a fullscreen activity and Home activity
simultaneously.
To fix the issue we set showHomeBehindStack to false when we reach
fullscreen activity in the activity stack.
This was made visible by the following commit:
446ef1de8d373c1b017df8d19ebf9a47811fb402
Change-Id: I535c1283a4e26f5cf606375b837d4b7195324af0
Symptom: ANR occurs on previous activity.
Root Cause:
In KK, when a background activity starts another existed background activity (bring to front),
if current focused stack is not the same as the stack of target starting activity,
it will still resume the top of target stack, even the top activity on the target stack may not the same as target activity.
And it will result incorrect focus, press back key will send to previous stack's top then popup ANR on previous activity:
"Reason: Waiting because no window has focus but there is a focused application".
By original code comment, it looks 'bring to front' should not happen in this issue case.
// If the target task is not in the front, then we need
// to bring it to the front... except... well, with
// SINGLE_TASK_LAUNCH it's not entirely clear. We'd like
// to have the same behavior as if a new instance was
// being started, which means not bringing it to the front
// if the caller is not itself in the front.
If the caller and target are in the same stask, it will just deliver new intent without changing task order (the same behavior as JellyBean).
So the patch concept is just to avoid to use target stack to resume top when caller and target are in different stack.
Solution: Do not allow to resume another stack top if non-top activity try to bring existed activity to front.
It may not be a good solution, just a reminder for the issue case.
Reproduce steps:
Assume A, B, C are different app tasks.
When the application stack is like:
Top C
B
A
#Case 1: Home is foreground
A starts B with NEW_TASK, C will resume, focus still stays at Home, and window order does not update.
Then press back key or volumn key will result ANR on Home.
#Case 2: App is foreground (Resumed activity is C)
A starts Home, Home will resume, focus still stays at C, and window order does did not update.
Then press back key or volumn key will result ANR on C.
Change-Id: If05070123b248e2335791e43a4d4ddee6db11d84
Basically WindowManagerService wait for finishing animation when
a window is removed. But when second display is disconnected, windows
on second display can't be shown even if animation is waited for.
On the contrary, it keeps on waiting for finishing the animation
in special case.
With this fix windows are immediately removed without waiting for
animation when second display is disconnected.
Change-Id: I1354c193c04db394a21a11c174e10c8e7da17a0e
Symptom: Unable to start any activity.
Root Cause: ActivityStack.mPausingActivity() points to a destroyed activity of a died process, so that ActivityStackSupervisor.allPausedActivitiesComplete() always returns false.
Solution: Set mPausingActivity to null in ActivityStack.cleanUpActivityLocked().
Reproduce steps:
a. Turn screen off.
b. A background service starts an activity X (in process X).
c. A background service starts a no-history activity Y (in process Y), but the main thread of Y was blocked.
d. A background service starts Y 3~4 times --> this causes am_failed_to_pause on X.
e. Main thread of Y is freed finally --> this causes Y crash for android.view.WindowManager$BadTokenException.
f. Turn screen on, X is shown on screen, but neither back key nor home key can work because mPausingActivity is Y.
Change-Id: I320b3db407e2d4cc745c8ca22a6e548742234242
The screenrecord command can record secure content during rotation.
This is because the ScreenshotSurface surface for rotation animation
is not set secure even though its screenshot contains secure content.
Change-Id: I5a70be71ddfc26de4230e7d4fe547210c2154210
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>
When persistent process with Service restarts, ActivityManagerService
does not reset ProcessRecord#hasClientActivites to false
(because ProcessRecord of persistent process is continued using
after killing).
It disturbs updating LRU list in ActivityManagerService, and then,
when new process calls ActivityManagerProxy#publishContentProviders,
SecurityException happens because of no entry in the list.
Bug: 13517358
Change-Id: I46b064f71a4f7025ade1bf117801352a7ab22e6a
