Swipe to dismiss on dialogs did not dispatch onCancel events
to OnCancelListeners. Resolve by adding listener to monitor
swipe to dismiss events and dispatch onCancel events when
that occurs.
Bug: 33663411
Change-Id: I64ff29e008d485a4559eb3d1ff7f0e74dccff404
Also adding same robustness to interrupt that we have for
sending a11y events.
Bug: 32507871
Test: Ran a11y CTS. Verified manually with sample app
that sends interrupt and accessibility service that
crashes when started. That case used to crash the
app, and doesn't anymore.
Change-Id: I5cf05dcbb54ea23ae876cb3258dd206c55dce775
(cherry picked from commit 867ad35d9c676b5ba2047b0fc9a4006737e5c4aa)
- move BroadcastReceiver info to developer guide. see cl/140402421
- add usage note to CONNECTIVITY_ACTION broadcast
bug:32533262
bug:33106411
Change-Id: Ic2aa517831d29418e0c42aa6fc1e7f9aeb50f802
is going idle.
The inputs to DeviceIdleController (alarm manager, sensors)
hold wake locks while they call it. But then the real work
happens in a handler which is outside of the wakelock, so
listeners don't get a chance to run right away, which in
the case of NetworkPolicyManager means the device is in a
higher power state than it should be.
It's not clear that this will 100% fix the bug, because
NetworkPolicyManagerService also has its own internal
Handler, and isn't holding its own wakelock for this,
but this change allows NPMS to be fixed if it really
needed to be.
Bug: 31900521
Change-Id: I706045aa189147824c9214c57abc13993aee9a5b
Consider the following situation:
1. Package is frozen.
2. We try forking the app while frozen, causing a ProcessRecord with
PID 0 to be recorded in mProcessNames. As a result of the failed
fork, removeProcessLocked() tears down that ProcessRecord, but a
special case records it into mRemovedProcesses.
3. Package is unfrozen.
4. We try forking the app, and this time it proceeds normally now
that we're unfrozen. The new valid ProcessRecord is recorded in
mProcessNames.
5. activityIdleInternalLocked() triggers a clean-up pass of
mRemovedProcesses. trimApplications() ends up cleaning up the
stale reference from (2) above *by hash key* and not *by reference*,
which causes us to remove the new valid ProcessRecord. This results
in the valid ProcessRecord in (4) becoming an orphaned PID, which
starts a chain reaction of havoc that ensues.
This issue is fixed by checking the expected ProcessRecord by value
before actually removing it, thus preventing orphaned PIDs.
Test: builds, boots, over 600 installs without orphaned PIDs
Bug: 28395549
Change-Id: I5ea1b31c3fd374ea7f5cc40ff35bb9195d9f3e2b
MemoryIntArray was using the size of the undelying
ashmem region to mmap the data but the ashmem size
can be changed until the former is memory mapped.
Since we use the ashmem region size for boundary
checking and memory unmapping if it does not match
the size used while mapping an attacker can force
the system to unmap memory or to access undefined
memory and crash.
Also we were passing the memory address where the
ashmem region is mapped in the owner process to
support cases where the client can pass back the
MemoryIntArray instance. This allows an attacker
to put invalid address and cause arbitrary memory
to be freed.
Now we no longer support passing back the instance
to the owner process (the passed back instance is
read only), so no need to pass the memory adress
of the owner's mapping, thus not allowing freeing
arbitrary memory.
Further, we now check the memory mapped size against
the size of the underlying ashmem region after we do
the memory mapping (to fix the ahsmem size) and if
an attacker changed the size under us we throw.
Tests: Updated the tests and they pass.
bug:33039926
bug:33042690
Change-Id: Ibf56827209a9b791aa83ae679219baf829ffc2ac
MemoryIntArray was using the size of the undelying
ashmem region to mmap the data but the ashmem size
can be changed until the former is memory mapped.
Since we use the ashmem region size for boundary
checking and memory unmapping if it does not match
the size used while mapping an attacker can force
the system to unmap memory or to access undefined
memory and crash.
Also we were passing the memory address where the
ashmem region is mapped in the owner process to
support cases where the client can pass back the
MemoryIntArray instance. This allows an attacker
to put invalid address and cause arbitrary memory
to be freed.
Now we no longer support passing back the instance
to the owner process (the passed back instance is
read only), so no need to pass the memory adress
of the owner's mapping, thus not allowing freeing
arbitrary memory.
Further, we now check the memory mapped size against
the size of the underlying ashmem region after we do
the memory mapping (to fix the ahsmem size) and if
an attacker changed the size under us we throw.
Tests: Updated the tests and they pass.
bug:33039926
bug:33042690
Change-Id: I1004579181ff7a223ef659e85c46100c47ab2409
