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 '155e3133407e590f18e7e16eddc6fc743f35b0fd':
[ActivityManager] Fix a bug: unable to start activity after starting activities during screen off.
* commit 'f10d0399bf5f519dff414a9d195a0eaacb37f9b7':
Made secure-adb's new-public-key activity configurable. Some devices do not have lockscreens themselves, so the plan is to have them do RPCs to companion devices that can have lockscreens, for allowing or rejecting unwhitelisted adb public keys.
Some devices do not have lockscreens themselves, so the plan is to have them
do RPCs to companion devices that can have lockscreens, for allowing or
rejecting unwhitelisted adb public keys.
Change-Id: I6f7504313074e6748c0bd467a29ac3a311036f4d
* 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>
The android.security.cts.ServicePermissionsTest--testDumpProtected test was
failing on this service because it is looking for the permission name in the
denial message.
Change-Id: I4b4d38cd27b782470d1f21e36104164d2c8962a3
Signed-off-by: Adam Hampson <ahampson@google.com>
When a Display has been removed there is a delay until all of its
windows have been removed. Therefore there is a possibility that
WindowState.getDisplayContent() returns null. Guard against that
possibility.
Fixes bug 13616765.
Change-Id: Ia2074d293b0e1bd4ca2cd14aeb4a2cc09ed9f41e
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
After being bound to, a NotificationListenerService could
make a call into NotificationManagerService before having been
added to the list of active services.
Bug: 13644375
Change-Id: I4ed920d165f46d009f91e28ca13c3926563cd110
It saves us from having to add numerous native methods to HdmiCecService.
A new native method that reports physical address was added in consequence
to be able to build the message in Java side.
Other changes:
- Substituted more concrete type (cec_device_type_t) to int.
- Fixed the issue about byte endianness in handling physical
address/vendor id. The bytes of variable mPhysicalAddress in native
service were being reversed previously but still worked because they
were reversed again when copied out to outgoing messages. Vendor id
had a bug of bytes being reversed. In order to fix the issue, the way
they are copied to byte array was changed so that it becomes
independent to byte endianness.
- CL's for header/HAL implementation changes are:
https://googleplex-android-review.git.corp.google.com/#/c/437667https://googleplex-android-review.git.corp.google.com/#/c/437668
Change-Id: Id1ac683fe54597a2c707f30492c7f86e5392504d
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
Do not remove an AppWindowToken or its Task if it is running an
animation. Doing so leaves windows orphaned and bad things happen
when the system tries to retrieve the task assoicated with the
windows during layout.
Fixes the ugly output associated with bug 13440426.
Change-Id: I9d5fc50a7cb6189160d51cee3c82f7813baee715
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
NotificationListener services would start too early
and crash due to system_server not being ready.
Bug: 13439345
Change-Id: I86ee93b50d016bfa0119e21a8cde8635212b16a4
