UserManager
- Corp badging
- Querying list of managed profiles
Launcher API
- LauncherApps and Service to proxy changes in managed profile
to the launcher in the primary profile
- Querying and launching launchable apps across profiles
Change-Id: Id8f7b4201afdfb5f414d04156d7b81300119289e
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
Adds the TrustManager system service that allows
registering for changes to the trust status and
reporting events that are important to trust agents.
Bug: 13723878
Change-Id: I7d0d2ea86fd755702d31aa5d49cac038a6cd4301
This isn't a straightforward conflict resolution. This code
has changed significantly. mSafeMode is now a flag on the activity
manager service, and is set when SystemServer calls enterSafeMode.
Change-Id: I1e8ff524566c5e44bb6bf3b138cdebb70004aca3
This field is written and read exclusively by the system server,
and should therefore belong to the SystemServer class.
Change-Id: I2708a9a45c0c9cd1a6f563e8cc5844bd8c424bf7
* commit 'd511bc17d614b1291f1b85f84180c1db157d2790':
[ActivityManager] Fix a bug: unable to start activity after starting activities during screen off.
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:
446ef1de8d
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
Add a dummy wifi hotspot service for futher development use. This is to
resolve the different between master branch and kwd branch, such that future
development can go into kwd and being auto-merged to master.
bug: 5485670
Change-Id: Ica58de445dd050a9f0b817f8e4accaa2478299c5
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
bug: 12033540
Expedited was previously tracked by a redundant internal variable, ostensibly
as an optimisation. This variable could differ from the value in the bundle
depending on how the operation is initialised, which led to confusion. Now an
expedited sync will only be treated as such on its first execution.
Change-Id: Ibfc4e9e49b86c82f2364a6ef55f887705a053eb6
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
On some devices, the USB "set configuration" command is propogated to the framework
after the "start accessory" event is received. However, on other devices like
the 2011 ADK board, no "set configuration" command is sent at all until we have
reenumerated in acccessory mode. To fix the original problem without breaking other
devices, we can simply remove assumptions about if or when "set configuration"
will be received. Now we simply remain switch USB configuration to accessory mode
when we receive the "start accessory" command, and remain there until the existing
10 second timeout expires.
Bug: 13393825
Change-Id: I4c9e3423185bd7252a907e4568d9e3ff06044b7d
This reverts commit fbd5521fb5.
This change broke support for the 2011 ADK board, which never sends a "set configuration"
command before "accessory start". So we revert this change and will replace it with a better fix.
Bug: 13535051
Bug: 13393825
Change-Id: Icd870d7ff6daff1567e04d93907f70f5d7e37884
In certain situations it was possible for a task to move to the top
in activity manager but not in window manager. This resulted in
the task appearing behind the launcher icons.
Fixes bug 13410184.
Change-Id: If0582b395e126a8aff70a0e4c64b731083c6ae8a
This CL adds a system service handling HDMI-CEC protocol. The service
is equipped with the capability sending/receiving HDMI-CEC messages
Not all the messages are in place. Currently it has messages to support
a few features only, as follows:
- One touch play
- System information
- Routing control (partially - active source status maintenance only)
- Device OSD transfer
- Power status
It will be extended to cover the wider usages in the follow up CLs.
The CEC standard version referenced in the implementation is 1.3a.
Change-Id: Ifed0b02f52ebf098eddb3bd0987efbf353b7e8fe
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 fixes a bug where an allocated DeathRecipient in WindowManagerService
was holding a reference to keyguard binder interface after a call to
linkToDeath() without a matchin unlinkToDeath().
It was causing the keyguard side of the binder interface to stick around,
which in tern prevented the keyguard side from releasing its references.
The solution is to ensure matching linkToDeath()/unlinkToDeath() calls.
Fixes bug 11982048
Change-Id: I6959816b819ba953512c53675162195cbf1e0653
