When a notification is ignored due to notification group optimization,
make sure any existing instance of the ignored notification is
canceled.
Bug: 18914108
Change-Id: Ifcc4833df019ea5cb7048eaab11ae76e7fa2a31c
MHL device works on hotplug but not when API deviceSelect is invoked
to select it due to a bug not finding the right MHL device instance.
This CL rectifies it by searching for not only CEC but MHL devices
attached to TV.
Bug: 18909552
Change-Id: I4df1ead836090eb3a7476b7738be47a6970edb7d
Symptom:
Remain dead process record in mLruProcesses.
Root cause:
When a process dies and needs to restart immediately.
The process record will not be removed from mLruProcesses
in handleAppDiedLocked (return kept=true).
If the restarting process start timeout, the record in
mLruProcesses will not be removed.
Solution:
Call removeLruProcessLocked in processStartTimedOutLocked.
Change-Id: I1935ccc586016cb4e90dfdfac96cc88931553d5f
The ShutdownActivity was implemented in the system server
code, which is no longer part of the boot class path. This would
work fine when requesting a shutdown from the primary user, since
in that case the activity would be loaded in to the main system
process which also has the system service code loaded.
However, when executed from a secondary user, we need to spin up
a new system process for it; that system process is just a regular
app process, without the system service code, so *boom*.
To fix this, move ShutdownActivity to the framework jar.
Change-Id: Icb831cd6ed619da5feede5605c45ef177a892fbc
The version of the warning with a named installer should be shown in
the case of a managed profile, not only a managed device.
Bug: 18224038
Change-Id: I58bddb162799481d5e8feb169b0c0bff17cbeeb7
memcpy() only copies the memory address value of device_info.audio_address,
and it could be invalid when onDeviceAvailable() is called.
Bug: 18819334
Change-Id: I827da8032a982abf3029874b8454ca79290bb0e0
(cherry picked from commit 898de6fd8c78d84ae1425e052b27a97ec6f230ad)
Symptom:
Assume a foreground broadcast FG and a background BG.
If a recevier registers both FG and BG. When sending
BG and FG to the receiver, and the receiver BG receiver
completes first, its finishReceiver will trigger next FG
receiver rather than BG, and also deliver wrong result
code/data to the next.
More detail and sample:
https://code.google.com/p/android/issues/detail?id=92917
Root cause:
Due to BroadcastQueue:getMatchingOrderedReceiver will match
by receiver(IBinder), so the caller ActivityManagerService:
broadcastRecordForReceiverLocked will always match the first
queue(fg) if a receiver is both receiving fg and bg.
Solution:
Add a parameter flags to finishReceiver, then server side
could know the finished receiver should belong to which queue.
Another general solution but with bigger scope:
I60dce4a48e20c1002a61a979e4d78b9b0a8b94a0
Change-Id: I913ca6f101ac8ec6c7a8e42754e6781f80247b7f
<Set System Audio Mode> is another command that needs to be buffered
in case the command arrives before the system is ready to process it.
When processed, system audio mode will be enabled based on the
global setting.
Bug: 18809965
Change-Id: Ia6ebc4e2919e1b94498ca28f652c6db95f907f9c
As per note this has been unused for upwards of 6 months and its
attribute string is no longer referenced anywhere else in Android.
Change-Id: I5f95ffa6b3d91fca203f2d030d40df3fd55b6a70
