Note DPM.wipeData() on a secondary user is now blocking, just like
it's been always blocking on the primary user.
Bug 30681079
Change-Id: Ia832bed0f22396998d6307ab46e262dae9463838
- Even if call setTestProviderLocation() with inconsistent providers,
should still end up with a location that is flagged as mocked
- Bug: 33091107
Change-Id: I39e038f25b975989c2e8651bfd9ec9e74073e6cd
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
We close the android logging related sockets prior as late as possible
before every fork to avoid having to whitelist them. If one of the
zygote's children dies after this point (but prior to the fork), we can
end up reopening the logging sockets from the SIGCHLD signal handler.
To prevent this from happening, block SIGCHLD during this critical
section.
Bug: 32693692
Test: Manual
(cherry picked from commit e9a525829a)
Zygote: Unblock SIGCHLD in the parent after fork.
Follow up to change e9a525829a. Allows the zygote to
receive SIGCHLD again and prevents the zygote from getting into a
zombie state if it's killed.
Contributed-By: rhed_jao <rhed_jao@htc.com>
Bug: 32693692
Test: manual
(cherry picked from commit 1480dc3e97)
Change-Id: If89903a29c84dfc9b056f9e19618046874bba689
Fix a idmap leak in AssetManager::addSystemOverlays.
And, The fix could also prevent fd leak of idmap.
Test: none
Bug: 32691930
Signed-off-by: Hyangseok Chae <neo.chae@lge.com>
(cherry picked from commit 6a742a3850)
Change-Id: Idc4af77db2b0cb739bd6b009b6af0f9123be1aac
On M and below, we provide a blanket whitelist for all files under
"/vendor/zygote_whitelist". This path is whitelisted purely to allow
this patch to be applied easily on legacy devices and configurations.
Note that this does not amount to a loosening of our security policy
because whitelisted files are reopened anyway.
Bug: 32691930
Test: manual
(cherry picked from commit 5e2f7c6229)
Change-Id: I9700fc7b469d0bc4d876c52292f25888b94a5223
Partially cherry picked from commit 1c15c63578.
These files are safe to reopen for the same reason that files in
/system/framework are. They're regular files and will not change after
the first zygote fork.
Bug: 32618130
Change-Id: I119e0bfcbf397cb331064adf148d92a5cd3ea92f
