A recent security fix prevents the system UID from handing out Uri
permission grants directly from itself. Instead, services need to
issue grants as the original calling UID to ensure that the caller
actually has access to the Uris.
Test: builds, boots, send/recv MMS works in primary/secondary users
Bug: 33231106
Change-Id: Ia9fe19843b52977c8a94ee5349b907beda1882fc
(cherry picked from commit 7ff418d9a9)
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)
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
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
setPairingConfirmation was set to only require BLUETOOTH_ADMIN
permission which shouldn't be able to set the confirmation itself.
This is restricted to BLUETOOTH_PRIVILEGED permission.
Bug: 29043989
Change-Id: Iddc935f0b02f5ff56e930914b4b664377e786184
We can no longer return the "my_downloads" paths: if those Uris were
shared beyond the app that requested the download, access would be
denied. Instead, we need to switch to using "all_downloads" Uris so
that permission grants can be issued to third-party viewer apps.
Since an app requesting a download doesn't normally have permission
to "all_downloads" paths, DownloadProvider now issues narrow grants
toward the owner of each download, both at device boot and when new
downloads are started.
Bug: 30537115, 30945409
Change-Id: I533125b36444877f54373d88922f2acc777e250b
setPairingConfirmation was set to only require BLUETOOTH_ADMIN
permission which shouldn't be able to set the confirmation itself.
This is restricted to BLUETOOTH_PRIVILEGED permission.
Bug: 29043989
Change-Id: I887de32d156e672ec44aa0b286cd7ea7f9f8ad55
