If permissions review is enabled we allow individual
control of fine graned permissions in the SMS group.
This change ensures these permissions use the
corresponding app op as a switch to allow indifidual
control.
Change-Id: I83cd78a78a8266df8324b8a10cd9e36c04ff3112
(cherry picked from commit 99e4d51584)
If multiple async shared preferences writes are queued, all but the
last one can be ignored as they will be overwritten by the last one
anyway.
For commit() we need to make sure that we have at least persisted the
state of the commit.
Generation counts are 64 bit, hence they never overflow.
Test: Produced a lot of SharedPreferences.Editor.apply and did not see
excessive writes anymore, ran SharedPreferences CTS tests
Bug: 33385963
Change-Id: I3968ed4b71befee6eeb90bea1666a0bb646544f6
(cherry picked from commit 31d6889f4c)
On FBE devices, don't save the metrics to disk but compute them when the
password is first entered and only store them in RAM.
Merged-in: 5daf273b7e
Bug: 32793550
Change-Id: Icee7f615167761177b224b342970a36c7d90f6ba
To understand this change it's first helpful to review Toasts.
The ViewRoot is constructed on the client side, but it's added,
to a window token controlled by the NotificationManagerService.
When we call NotificationManagerService#cancelToast, the system
will remove this window token. With the window token removed,
the WindowManager needs to destroy the surface to prevent orphaned
windows. If we destroy the Surface before removing the toast on the
client side however, we've never asked the ViewRoot to stop rendering
and we could have a crash. To solve this we just have to ensure we call
removeView before cancelToast.
Bug: 31547288
Bug: 30150688
Change-Id: Ic7e8914a7fb2134a8b9e0c2f3810d7f075c8391e
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 867ad35d9c)
Avoid potential race condition between FRP wipe and write operations
during factory reset by making the FRP partition unwritable after
wipe.
Bug: 30352311
Test: manual
Change-Id: If3f024a1611366c0677a996705724458094fcfad
(cherry picked from commit a629c772f4)
- move BroadcastReceiver info to developer guide. see cl/140402421
- add usage note to CONNECTIVITY_ACTION broadcast
bug:32533262
bug:33106411
Change-Id: Ic2aa517831d29418e0c42aa6fc1e7f9aeb50f802
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
