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>
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
When a client of the NsdService exits, NsdService should
clean up the requests it has sent to the mDNS daemon:
cancel any pending resource-discovery and resource-resolution
queries, and remove any services registered by this client.
If this isn't done, several bad things happen. The daemon will
continue to run unnecessarily, will report service discoveries
that can't be forwarded on to the client, and will continue to
advertise service ports for an application which is no longer
running until the device is rebooted (mDNS pollution).
Bug: 9801184
Change-Id: I0aa7311480322aefcff16f902fbbf34f50985d38
If userId doesn't change, no need to do switchuser.or it will
introduce some tweak for gps modules in quick off/on because
they need cost time in off/on.
Change-Id: Ie5e408dc8be69c8a63a18bcb2cfe478cef4d70e6
Signed-off-by: Jianzheng Zhou <jianzheng.zhou@freescale.com>
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
- Introduce a boolean extra for intent TIME_CHANGED that
specifies if the user wants a 24 hour format or not.
- Have the ActivityManagerService inform running processes
of changes to this preference.
- Add plumbing in ActivityThread to inform j.t.DateFormat
Change-Id: I05fafb903ae54e39c03a048b7a219dc5a93fd472
When WindowManagerService creates a new Task, it passes atoken to the
Task constructor. In this case atoken is added to mAppTokens list by
the Task constructor and then it is added manually again by calling
newTask.mAppTokens.add(atoken). As a result, the same atoken is present
in mAppTokens list twice.
When another window token is added to the list, it may be placed in
beetwen duplicated tokens and corresponding window will be hidden from
the screen by corresponding duplicated windows.
From user perspective it means that some windows will not be displayed
on the screen.
The issue is fixed by avoid adding atoken to mAppTokens list manually
when it was added already in Task constructor.
Change-Id: I10628e68186160fffdde07beb7d84ab3cecb7051
On devices using /dev/rtc instead of /dev/alarm, updating the
time-of-day clock and RTC are separate syscalls. Hence the clock and
RTC could be left in inconsistent states if two threads called
SystemClock.setCurrentTimeMillis() simultaneously.
By moving this code into AlarmManagerService, we can put a global lock
around AlarmManagerService.setTime() and prevent the race condition.
Note that access to SystemClock.setCurrentTimeMillis() is now gated by
android.permission.SET_TIME, where before it was gated by filesystem
permissions (i.e., could the process write to /dev/alarm or /dev/rtc).
Change-Id: Ia34899a4cde983656305fd2ef466dfe908ed23c8
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Changes in this patch include
[x] Long(64-bit) is used to store native pointers in
AssetAtlasService and related classes as they can be 64-bit.
[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: Ib4c77c134e3ad5b21732e20cde9a54a0b16bdab1
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
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
The event onShutDownComplete are sent only when all
volumes are shutdown. (Not one for every volume.)
Change-Id: I6af521ee8285ca581efac7d3c5f013dfbff3ee30
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
Changes in this patch include
[x] Long is used to store native pointers as they can
be 64-bit.
[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)
[x] AssetAtlasManager is not completely 64-bit compatible
yet. Specifically mAtlasMap member has to be converted
to hold native pointer using long. Added a TODO to
AssetAtlasManager.java to indicate the change required.
Change-Id: I940433f601c6db998c1a8ffff338f5361200d5ed
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>
Symptom:
When press Home key to home screen, user is able to see the activity's window shown on top of wallpaper and below launcher(widgets).
Root Cause:
The ensureActivitiesVisibleLocked() is called pretty often (for example when a new process bound).
If the top activity "B" was finishing, then the previous activity "A" should be visible.
Therefore, the activity "A" window will be set to visible and then launched activity "A", but it does not updates the visible state in ActivityRecord for "A".
There has a timing issue that if a new activity "C" is started, "C" becomes the new top activity and be resumed.
In that case, Activity "A" window will remain visible even if it is behind a full screen activity "C" because the ActivityRecord.visble of "A" is still false, so the window visibility won't be update.
So when user press home key and back to launcher, the surface of activity "A" will be composed on top of wallpaper.
Solution:
Updates ActivityRecord.visible to true for "A". After "C" is started, the "A" will be called WindowManagerService.setAppVisibility() to set invisible, then called onStop() when execute ensureActivitiesVisibleLocked() again.
Change-Id: I536ba04b95d8d274fea6d679a6493e620bc981e2
Only one entry is allowed to be added to route table 60 for all
interface ipv6 link local addresses, so skip ipv6 link local
addresses on all interfaces when enabling NAT
Change-Id: Ibbe6c2bdae83586cdd38287089715f3433bbb91f
Signed-off-by: jiaguo <jiaguo@marvell.com>
setLightLocked() will update mColor. This will cause the led to not be
turned off after the pulse.
When notificationManager starts a attention pulse the led will be kept
on. Since attention is of highest prio nothing can turn it off.
This is fixed by resetting mColor back to 0 after the call.
Change-Id: Id60ef96e5c21b47c23002f0bcf2fae7fb3f2ca10
