This is a backport of ag/7528082 and ag/20033068.
Bug: 132319116
Bug: 130571162
Bug: 204584366
Test: CTS Verifier: USB Accessory Test & USB Device Test
Change-Id: I952ab566e26a808997e362dc85ebd1d8eb4574b9
This app-generated input needs to not be too long to avoid errors in the process of writing to disk.
Bug: 242846316
Test: cts ConditionTest; atest ConditionTest; manually verified exploit apk is OK
Change-Id: Ic2fa8f06cc7a4c1f262115764fbd1be2a226b4b9
Merged-In: Ic2fa8f06cc7a4c1f262115764fbd1be2a226b4b9
(cherry picked from commit 81352c3775)
This change both prevents any rules from being unable to be written to disk and also avoids risk of running out of memory while handling all the zen rules.
Bug: 242703460
Bug: 242703505
Bug: 242703780
Bug: 242704043
Bug: 243794204
Test: cts AutomaticZenRuleTest; atest android.app.AutomaticZenRuleTest; manually confirmed each exploit example either saves the rule successfully with a truncated string (in the case of name & conditionId) or may fail to save the rule at all (if the owner/configactivity is invalid). Additionally ran the memory-exhausting PoC without device crashes.
Change-Id: I110172a43f28528dd274b3b346eb29c3796ff2c6
Merged-In: I110172a43f28528dd274b3b346eb29c3796ff2c6
(cherry picked from commit de172ba0d4)
The service must have the CAPTURE_AUDIO_HOTWORD permission to access
AlwaysOnHotwordDetector. If it doesn't have the permission, return
STATE_HARDWARE_UNAVAILABLE state. If it is not granted the
RECORD_AUDIO permisison, it also can't start to recognize the audio.
Test: manual
Test: atest CtsVoiceInteractionTestCases
Test: atest CtsAssistTestCases
Bug: 229793943
Change-Id: I7d0f8d2f6af4bc4210060f0a44469db2afc7a1bb
Merged-In: I7d0f8d2f6af4bc4210060f0a44469db2afc7a1bb
Test: Manually install app apks targeting Q and verifying that AR permission is not auto-granted
Test: atest ActivityRecognitionPermissionTest
Bug: 210065877
Change-Id: I90adf45a6611ab8bc953765c72af77a6a4f7aae8
Before, it was like getting a used pan with food stuck on it. We run
a clean ship here. You want a Parcel? You get a fresh Parcel. When
we recycle a Parcel, we do a real clean-up job. Air freshener. All
bits brushed over. These Parcel objects are clean as heck now!
(specifically cleans mClassCookies)
Bug: 208279300
Test: build
Merged-In: I250872f5c6796bb64e2dc68008154c0e90feb218
Change-Id: I250872f5c6796bb64e2dc68008154c0e90feb218
(cherry picked from commit 46770fa49c)
Bug: 203229608
Test: Manual test with changing the check logic + debug log
Change-Id: If18009f61360564d02dcda9b1e5fa15685e3250f
(cherry picked from commit 58270527d1)
Make sure only the app currently interacting with the IME can
query this, and restrict the API to apps targeting SDKs before T
Fixes: 204906124
Test: atest 'InputMethodManagerTest#getInputMethodWindowVisibleHeight_returnsZeroIfNotFocused'
Change-Id: If1da19a3dd8c29542afc970b4b201d87547c27a9
Merged-In: If1da19a3dd8c29542afc970b4b201d87547c27a9
Duplicate permissions definition with different group allows
privilege permission escalation to a different permission group.
Android studio and gradle plugin does not allow duplicate
permissions with different attributes, these tools only allow
if duplicate permissions are exact copies.
Also platform stores permissions in map at multiple places with
permission name as key. This suggests that we can disallow
duplicate permissions during package install/update.
Bug: 213323615
Test: manual
Change-Id: I6f44e740897305e7a0553c1cf6c3af37faf02a2e
Merged-In: I1910dca44104e35a57eba4acfa8188cd9b8626ac
Merged-In: I34120fff2ec2a158dfa55779d2afd4bbd49487ff
Merged-In: I9bc839836786a0876e67fd73c05f8944bb532249
* changes:
[RESTRICT AUTOMERGE] Log to EventLog on prepareUserStorage failure
[RESTRICT AUTOMERGE] Ignore errors preparing user storage for existing users
[RESTRICT AUTOMERGE] UserDataPreparer: reboot to recovery for system user only
[RESTRICT AUTOMERGE] UserDataPreparer: reboot to recovery if preparing user storage fails
[RESTRICT AUTOMERGE] StorageManagerService: don't ignore failures to prepare user storage
Check user unlocked before write to /data/system_ce/0/snapshots
Unfortunately we can't rule out the existence of devices where the user
storage wasn't properly prepared, due to StorageManagerService
previously ignoring errors from mVold.prepareUserStorage, combined with
OEMs potentially creating files in per-user directories too early. And
forcing these broken devices to be factory reset upon taking an OTA is
not currently considered to be acceptable.
One option is to only check for prepareUserStorage errors on devices
that launched with T or later. However, this is a serious issue and it
would be strongly preferable to do more than that.
Therefore, this CL makes it so that errors are checked for all new
users, rather than all new devices. A field ignorePrepareStorageErrors
is added to the user record; it is only ever set to true implicitly,
when reading a user record from disk that lacks this field. This field
is used by StorageManagerService to decide whether to check for errors.
Bug: 164488924
Bug: 224585613
Test: Intentionally made a device affected by this issue by reverting
the CLs that introduced the error checks, and changing vold to
inject an error into prepareUserStorage. Then, flashed a build
with this CL without wiping userdata. The device still boots, as
expected, and the log shows that the error was intentionally
ignored. Tested that if a second user is added, the error is
*not* ignored and the second user's storage is destroyed before it
can be used. Finally, wiped the device and verified that it won't
boot up anymore, as expected since error checking is enabled for
the system user in that case.
Change-Id: I9bdd1a4bf5b14542adb901f264a91d489115c89b
(cherry picked from commit 60d8318c47)
Merged-In: I9bdd1a4bf5b14542adb901f264a91d489115c89b
GateKeeperResponse has inconsistent writeToParcel() and
createFromParcel() methods, making it possible for a malicious app to
create a Bundle that changes contents after reserialization. Such
Bundles can be used to execute Intents with system privileges.
We fixed related issues previously for GateKeeperResponse class, but
one of the case was remaining when payload is byte array of size 0,
Fixing this case now.
Bug: 220303465
Test: With the POC provided in the bug.
Change-Id: Ida28d611edd674e76ed39dd8037f52abcba82586
Merged-In: Ida28d611edd674e76ed39dd8037f52abcba82586
(cherry picked from commit 46653a91c3)
Change-Id: I486348c7a01c6f59c952b20fb4a36429fff22958
