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)
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
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: Id7f0e8a4c861b0b9fa796767e0c22d96633b14d1
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: Ie267646eb88014034fbd048d7a9bc273420c7eff
As part of fixing a recent security issue, DownloadManager now needs
to issue Uri permission grants for all downloads. However, if an app
that requested a download is upgraded or otherwise force-stopped,
the required permission grants are removed.
We could tell DownloadManager about the app being stopped, but that
would be racy (due to background broadcast), and waking it up would
degrade system health. Instead, as a special case we now only
consider clearing DownloadManager permission grants when app data
is being cleared.
Bug: 32172542, 30537115
Test: builds, boots, app upgrade doesn't clear grants
Change-Id: I7e3d4546fd12bfe5f81b9fb9857ece58d574a6b9
(cherry picked from commit 23ec811266)
As part of fixing a recent security issue, DownloadManager now needs
to issue Uri permission grants for all downloads. However, if an app
that requested a download is upgraded or otherwise force-stopped,
the required permission grants are removed.
We could tell DownloadManager about the app being stopped, but that
would be racy (due to background broadcast), and waking it up would
degrade system health. Instead, as a special case we now only
consider clearing DownloadManager permission grants when app data
is being cleared.
Bug: 32172542, 30537115
Test: builds, boots, app upgrade doesn't clear grants
Change-Id: I7e3d4546fd12bfe5f81b9fb9857ece58d574a6b9
(cherry picked from commit 23ec811266)
As part of fixing a recent security issue, DownloadManager now needs
to issue Uri permission grants for all downloads. However, if an app
that requested a download is upgraded or otherwise force-stopped,
the required permission grants are removed.
We could tell DownloadManager about the app being stopped, but that
would be racy (due to background broadcast), and waking it up would
degrade system health. Instead, as a special case we now only
consider clearing DownloadManager permission grants when app data
is being cleared.
Bug: 32172542, 30537115
Test: builds, boots, app upgrade doesn't clear grants
Change-Id: I7e3d4546fd12bfe5f81b9fb9857ece58d574a6b9
(cherry picked from commit 23ec811266)
As part of fixing a recent security issue, DownloadManager now needs
to issue Uri permission grants for all downloads. However, if an app
that requested a download is upgraded or otherwise force-stopped,
the required permission grants are removed.
We could tell DownloadManager about the app being stopped, but that
would be racy (due to background broadcast), and waking it up would
degrade system health. Instead, as a special case we now only
consider clearing DownloadManager permission grants when app data
is being cleared.
Bug: 32172542, 30537115
Test: builds, boots, app upgrade doesn't clear grants
Change-Id: I7e3d4546fd12bfe5f81b9fb9857ece58d574a6b9
(cherry picked from commit 23ec811266)
For an app to either send or receive content change notifications,
require that they have some level of access to the underlying
provider.
Without these checks, a malicious app could sniff sensitive user data
from the notifications of otherwise private providers.
Test: builds, boots, PoC app now fails
Bug: 32555637
Change-Id: If2dcd45cb0a9f1fb3b93e39fc7b8ae9c34c2fdef
For an app to either send or receive content change notifications,
require that they have some level of access to the underlying
provider.
Without these checks, a malicious app could sniff sensitive user data
from the notifications of otherwise private providers.
Test: builds, boots, PoC app now fails
Bug: 32555637
Change-Id: If2dcd45cb0a9f1fb3b93e39fc7b8ae9c34c2fdef
For an app to either send or receive content change notifications,
require that they have some level of access to the underlying
provider.
Without these checks, a malicious app could sniff sensitive user data
from the notifications of otherwise private providers.
Test: builds, boots, PoC app now fails
Bug: 32555637
Change-Id: If2dcd45cb0a9f1fb3b93e39fc7b8ae9c34c2fdef
For an app to either send or receive content change notifications,
require that they have some level of access to the underlying
provider.
Without these checks, a malicious app could sniff sensitive user data
from the notifications of otherwise private providers.
Test: builds, boots, PoC app now fails
Bug: 32555637
Change-Id: If2dcd45cb0a9f1fb3b93e39fc7b8ae9c34c2fdef
For an app to either send or receive content change notifications,
require that they have some level of access to the underlying
provider.
Without these checks, a malicious app could sniff sensitive user data
from the notifications of otherwise private providers.
Test: builds, boots, PoC app now fails
Bug: 32555637
Change-Id: If2dcd45cb0a9f1fb3b93e39fc7b8ae9c34c2fdef
from AOSP: https://android-review.googlesource.com/#/c/209490/
Frameworks supported a mature mechanism for shader cache per each package already,
but as a special case such as Settings APP, if there are several packages in this
application which means that multiple packages shared the same SharedUserID with it,
it won't initialize the graphics disk caches, thereby APP like Settings have to
rebuild and relink shader every time during launch, which cause a bad launching
performance, so here to enable the GFX and RS cache initialization for multiple
shared packages case too.
Change-Id: If0f927e3399b775804abf1d9a868887951f471c5
Signed-off-by: Shuo Gao <shuo.gao@intel.com>
Signed-off-by: Zhiquan Liu <zhiquan.liu@intel.com>
from AOSP: https://android-review.googlesource.com/#/c/183305/
On the critical path of the cold launch of applications
the main thread of the started application tells the RenderThread
to create a surface. This process is synchronous and blocks
the main thread of the application until the creation
of the EGLContext is complete.
As a consequence the launch time of the application is delayed
by time spent allocating the EGL Context in the RenderThread.
With this optimization the launch time of any application
is improved (for example settings by 20 to 40 ms).
Change-Id: Ibf47aaa0abb8dedf7aa00693073db3785d9d6b08
Signed-off-by: Thomas Buhot <thomas.buhot@intel.com>
Signed-off-by: Zhiquan Liu <zhiquan.liu@intel.com>
Added a service that listens whether emergency affordances
are necessary.
If the they are needed, it adds an option to the
global actions dialog that directly launches the
emergency call and also adds a long-press listener
to the keyguard emergency button.
Test: adb shell settings put global force_emergency_affordance 1 && adb shell settings put global emergency_affordance_number 111112
Bug: 30404490
Change-Id: Ib96a15da2ef4b568a8d77140ebca6aa6f20f5ddb
Added a service that listens whether emergency affordances
are necessary.
If the they are needed, it adds an option to the
global actions dialog that directly launches the
emergency call and also adds a long-press listener
to the keyguard emergency button.
Test: adb shell settings put global force_emergency_affordance 1 && adb shell settings put global emergency_affordance_number 111112
Bug: 30404490
Change-Id: Ib96a15da2ef4b568a8d77140ebca6aa6f20f5ddb
Added a service that listens whether emergency affordances
are necessary.
If the they are needed, it adds an option to the
global actions dialog that directly launches the
emergency call and also adds a long-press listener
to the keyguard emergency button.
Test: adb shell settings put global force_emergency_affordance 1 && adb shell settings put global emergency_affordance_number 111112
Bug: 30404490
Change-Id: Ib96a15da2ef4b568a8d77140ebca6aa6f20f5ddb
