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)
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
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
Don't write partial requests, and don't return (or throw) early after
partially reading a response.
bug: 30143607
(cherry-picked from commit 448be0a622)
Change-Id: I5881fdd5e81023cd21fb4d23a471a5031987a1f1
Get the canonical identity and metadata about the package from the
Package Manager at time of usage rather than rely on the caller to
have gotten things right, even when the caller has the system uid.
Bug 28795098
Change-Id: I215786bc894dedf7ca28e9c80cefabd0e40ca877
