These shell commands were implicitly deleting any client-named file for
which the system uid had deletion capability. They no longer do this,
instead using only the client's own capabilities and file manipulation
modes.
Bug: 185398942
Test: manual "adb shell cmd activity dumpheap system_server /data/system/last-fstrim"
Test: atest CtsPermissionTestCases:ShellCommandPermissionTest
Merged-In: Ie61ab2c3f4bfbd04de09ca99c1116d1129461e8f
Change-Id: Ie61ab2c3f4bfbd04de09ca99c1116d1129461e8f
If updateLockscreenTimeout gets called before the Runnable queued
from lockNow gets executed, lockNow request will be ignored. Fix
this by not clearing out the runnable if it's pending lock request.
Test: Switch user, ensure lockscreen comes up
Bug: 161149543
Change-Id: Ie486396fd7328edf8ca0912df92524bb82a1fb7f
(cherry picked from commit 875fa991aa)
Merged-In: Ie486396fd7328edf8ca0912df92524bb82a1fb7f
NetworkMonitor sends "android.net.conn.NETWORK_CONDITIONS_MEASURED"
broadcast with Wifi SSID & BSSID. The receiver of this broadcast
is only required to have "android.permission.ACCESS_NETWORK_CONDITIONS"
permission but not the "android.permission.ACCESS_FINE_LOCATION".
It's incorrect because if the apps want to know the Wifi SSID and
BSSID, they should get the run-time permission with user consent.
Since this broadcast is not used anymore, delete it and the related
code.
Bug: 175213041
Test: atest NetworkStackNextTests NetworkStackTests
Change-Id: I12050737291c7fa0ebff4e7411b91f4c6f57a413
Merged-In: I12050737291c7fa0ebff4e7411b91f4c6f57a413
Merged-In: I7b43940dc32826c70fa82f471b35bc5cb8394aad
Work challenge did not show when a work activity is not on top, but
still visible after screen turns on.
Also show work challenge even if the work activity is behind a top
fullscreen activity of another profile because the user can still
navigate back to the work activity when top activity finishes.
Bug: 177457096
Test: ActivityStackSupervisorTests
Change-Id: I5e09b09be547d04fdfd709cb9cd4bcd4a94bbf21
Merged-In: I5e09b09be547d04fdfd709cb9cd4bcd4a94bbf21
This change enforces that only system, root or shell may call
getAllPackages(), a hidden API that shares all package names regardless
of user, instant app or package visibility rules.
Bug: 174661955
Change-Id: I77460ae19a4d41151577646441f11e2eddbb741a
Merged-In: I77460ae19a4d41151577646441f11e2eddbb741a
(cherry picked from commit 8124efd57b)
Reason for revert: Punted to future release due to invalid fix
Bug: 175319005
Merged-In: I00b78d596ee05c5a4a228771bbf8082af2b0ab8a
Change-Id: I78284e0a0dd5c41345753cdd2ed9a518db1df930
Currently, we keep the process up even if the user switches,
meaning that in some cases (if the user is switched while the
screenshot UI is up) we will save images to the wrong profile.
This change makes ScreenshotHelper listen for user switches and
close the screenshot service, so that a new screenshot is
guaranteed to be constructed with the correct user's context.
Bug: 170474245
Fix: 170474245
Test: manual -- verified bad state occurs if user switches within
the timeout period, ensured that screenshots work immediately
after switching with this change.
Change-Id: I9d32d0928e6c2bda161d04555438d0dd7afef0ba
(cherry picked from commit 7ef1a5dd15)
Auto verification of app links requires that an intent filter declare
action=VIEW, scheme=HTTP(S), category=BROWSABLE. However,
PackageManagerService was not taking that into account, missing the
category requirement.
But the app info Settings UI did take category into account, so it was
possible for a user to set an application to automatically open web URIs
without understanding that this also granted domains that were not
visible in the app info UI.
To resolve both this, this change makes it so that both auto
verification and the Settings state can only consider the app as
"always" open only if the Intent contains both BROWSABLE and DEFAULT.
Bug: 175139501
Bug: 175319005
Test: manual, see bug for reproduction steps
Merged-In: Ib957258735893bf2779bed19bd400c6726ee6478
Change-Id: Ib957258735893bf2779bed19bd400c6726ee6478
(cherry picked from commit 4266f938c6)
NO_INPUT_CHANNEL is a hidden WM flag that allows creation of a window
without an input channel. Unfortunately in releases prior to Android R
this would allow creation of a Window which will not be known to the
InputDispatcher at all. This means that the logic generating
FLAG_OBSCURED will work and a window will be able to overlay another
window without the overlayed window being notified. In Android R and
later this isn't a problem as the InputDispatcher is informed of all
windows, input channel or not. For past Android releases, this patch
disables NO_INPUT_CHANNEL for use outside of the WM.
Bug: 152064592
Test: Existing tests pass
Change-Id: I7e1f45cba139eab92e7df88d1e052baba0ae2cc6
If a permission owner changes, or a permission level is upgraded, revoke
the permission from all packages
Test: Manual
Bug: 154505240
Merged-In: I0dec9eb7c2fecd3147e33e04d3f79f6dffcf7721
Change-Id: I2b3780ba3ae5147026d4c85b3526fe1807724be6
(manually backported from commit a28931a098)
Not only on normal -> runtime.
Test: cts-tradefed run cts-dev -m CtsAppSecurityHostTestCases --test android.appsecurity.cts.PermissionsHostTest#testNoPermissionEscalationAfterReboot
Bug: 154505240, 168319670
Change-Id: If3b420067b4d7111dcf67ae6f98e42176158b679
Merged-In: If3b420067b4d7111dcf67ae6f98e42176158b679
Due to a race condition with activity task stack broadcasts, it's
currently possible for fingerprint authentication to succeed for a
non-top activity. This means, for example, that a malicious overlay
could be drawn in order to mislead the user about what they are
authenticating for.
This commit addresses the issue by adding a check to the fingerprint
authentication client interface that ensures the authenticating
activity is on top at the time of authentication. Otherwise, the
pending authentication will fail, as if an incorrect biometric
been presented.
Test: Follow steps from b/159249069:
1. Install com.pro100svitlo.fingerprintauthdemo from the Play store.
2. Install the PoC attack app from b/159249069.
3. Start the PoC attack app and press the "Launch PoC attack" button.
4. Use fingerprint to authenticate while the overlay is showing.
Before: Authentication succeeds, and a new activity is launched.
After: Authentication fails, and no new activity is launched.
Bug: 159249069
Change-Id: I0707c3f55eaf2a69c6625a3ceb3b5626b3676b26
Merged-In: If5cdf8ffaf3aa7d8a1ac81272e3bfb2cc7cdddf1
Merged-In: Iee6af379515385777984da55048c1efd9339ed88
Merged-In: I9b242a9fee0acbfb430875061e2d809c00fe4b97
Merged-In: I1241a12eafa0bdbac59a8ddd4cf6a0637d467b19
Merged-In: Ie5a0f8c3e9b92d348a78678a6ed192d440c45ffc
Merged-In: I289d67e5c7055ed60f7a96725c523d07cd047b23
When user is stopped, the Vpn#onUserStopped() will be called and
the value of mLockdown will be set to false then store into
setting.
This is a wrong behavior because user doesn't change it, so for
this kind of case, there is no need to store the value of
mLockdown in setting.
In fact, there is no need to call Vpn#saveAlwaysOnPackage() when
user is stopped because there is nothing changed.
Bug: 168500792
Test: atest FrameworksNetTests
Change-Id: Ie85a347216614b7873bfdf199165d89527ada3a8
Require that the PendingIntent be immutable so that a malicious app is
not able to hijack and mutate any of the details.
Fixes: 154915372
Test: build & flash, change wallpaper manually.
Change-Id: I59b48811b26736bf0575769107dd940ca33ccf8d
(cherry picked from commit d4bd69cef0)
Require that the PendingIntent be immutable so that a malicious app is
not able to hijack and mutate any of the details.
Fixes: 154915372
Test: build & flash, change wallpaper manually.
Change-Id: I59b48811b26736bf0575769107dd940ca33ccf8d
(cherry picked from commit d4bd69cef0)
Do not set referrerUri on SessionInfo for non-owners
This change leaves the referrerUri field null when the caller leading to
its production is not the owner of the session.
Bug: 142125338
Test: Manual via test app in related bug
Change-Id: I84679ea0636aa2097e25e23813c48134c9cc1d75
Bug: 160390416
Test: verified command still works from shell
Change-Id: I23bb06e00f1623e4f27c02d7eb2c0d273b40771b
(cherry picked from commit 0354261197)
Merged-In: I23bb06e00f1623e4f27c02d7eb2c0d273b40771b
Bug: 160390416
Test: verified command still works from shell
Change-Id: I23bb06e00f1623e4f27c02d7eb2c0d273b40771b
(cherry picked from commit 0354261197)
Merged-In: I23bb06e00f1623e4f27c02d7eb2c0d273b40771b
Re-run app link verification at update time only when the set of hosts
has expanded. Intentionally revoke verify history when an app stops
using autoVerify, as a one-time measure to place it back into the
non-autoverify model for tracking the user's launch preferences. If the
app starts using autoVerify again later, it behaves identically to an
app that has never done so before.
Bug: 151475497
Bug: 146204120
Test: described on master CL
Merged-In: I200d85085ce79842a3ed39377d1f75ec381c8991
Merged-In: Ibaf087946966ad82d60c7b255e3ee75990716b63
Change-Id: Ibaf087946966ad82d60c7b255e3ee75990716b63