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
A malicious application could overlay the activity. The overlay is
able to be tapped through, which can trick the user into starting a
harmful activity.
The CL added the flag SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS for
the activity to prevent the tapjacking/overlay attack.
Bug: 205595291
Test: atest CtsHarmfulAppWarningHostTestCases
Change-Id: Ia1a1ae0dc451e04bf5c31e3cb8cf30a0d8e32991
(cherry picked from commit a04b3666b8)
This reverts commit 4d91b5aa0b.
Reason for revert: will deliver a better fix for that, ag/16580245.
Change-Id: I8691f47251157aae83d326eb808dd1c06b13a420
The size of the input of both setStream and setResource may very big
that system server got oom while handling it, so we try to decode it
first before copying it to the wallpaper path, if the decoding fails, we
treat the input as an invalid input.
Bug: 204087139
Test: Manually set wallpaper, no PDoS observed.
Change-Id: I014cf461954992782b3dfa0dde67c98a572cc770
Prevents non-system apps from placing a window over the app selection
screen.
Bug: 143559931
Test: Installed test app and attempted to overlay
Change-Id: Ied05088a5007e0f10cd3e1abd8d7da8ffeb3b674
Merged-In: Ied05088a5007e0f10cd3e1abd8d7da8ffeb3b674
(cherry picked from commit 34534e1fd2)
See comment here for the discussion on solution
https://b.corp.google.com/issues/169762606#comment14
Change-Id: If212df3a3b7be1de0fb26b8e88b2fcbb8077c253
Bug: 169762606
(cherry picked from commit 11053c17b3)
Change-Id: I6494366a5695daedc3f4f0046da9e130a5363f5f
Merged-In: If212df3a3b7be1de0fb26b8e88b2fcbb8077c253
The system is overwhelmed by an enormous label string returned by
the load label api. This cl truncates the label string if it exceeds
the maximum safe length.
Also update the max safe label length to 1000 characters, which is
enough.
Bug: 67013844
Test: atest PackageManagerTest
Change-Id: Ia4d768cc93a47cfb8b6f7c4b6dc73abd801809bd
Merged-in: Ia4d768cc93a47cfb8b6f7c4b6dc73abd801809bd
The system is overwhelmed by an enormous label string returned by
the load label api. This cl truncates the label string if it exceeds
the maximum safe length.
Also update the max safe label length to 1000 characters, which is
enough.
Bug: 67013844
Test: atest PackageManagerTest
Change-Id: Ia4d768cc93a47cfb8b6f7c4b6dc73abd801809bd
Merged-in: Ia4d768cc93a47cfb8b6f7c4b6dc73abd801809bd
The system is overwhelmed by an enormous label string returned by
the load label api. This cl truncates the label string if it exceeds
the maximum safe length.
Also update the max safe label length to 1000 characters, which is
enough.
Bug: 67013844
Test: atest PackageManagerTest
Change-Id: Ia4d768cc93a47cfb8b6f7c4b6dc73abd801809bd
Merged-in: Ia4d768cc93a47cfb8b6f7c4b6dc73abd801809bd
Do not catch exceptions when we attempt to create the following classes
from a parcel
- OutputConfiguration
- VendorTagDescriptor
- VendorTagDescriptorCache
- SessionConfiguration
This could cause subsequent parcel information to be read incorrectly.
Bug: 188675581
Test: Sample app which tries to write invalid data into an
OutputConfiguration parcel to send in an intent via Broadcast. When read by the receiving app,
gets an exception (not swallowed).
Merged-In: I745ca49daa6ca36b1020d518e9f346b52684f2b1
Change-Id: I745ca49daa6ca36b1020d518e9f346b52684f2b1
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
(cherry picked from commit 6b0bcd60c8)
Do not catch exceptions when we attempt to create the following classes
from a parcel
- OutputConfiguration
- VendorTagDescriptor
- VendorTagDescriptorCache
- SessionConfiguration
This could cause subsequent parcel information to be read incorrectly.
Bug: 188675581
Test: Sample app which tries to write invalid data into an
OutputConfiguration parcel to send in an intent via Broadcast. When read by the receiving app,
gets an exception (not swallowed).
Merged-In: I745ca49daa6ca36b1020d518e9f346b52684f2b1
Change-Id: I745ca49daa6ca36b1020d518e9f346b52684f2b1
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
(cherry picked from commit 6b0bcd60c8)
This is a CP of ag/14736230 to qt-dev.
Apps were able to bypass BAL and BG-FGS restrictions by retrieving their
own notifications and firing their PI since those were allowlisted for
those operations.
Now we strip the token that granted them that ability
from notifications returned via NM.getActiveNotifications(), which
returns the notifications of the caller.
Notifications returned via notification listener APIs still contain such
token, as they should.
Bug: 185388103
Bug: 169821287
Test: Manually tested
Change-Id: I2ede0d639a560f6acacec3864a0a7d23af152ba5
Merged-In: I2ede0d639a560f6acacec3864a0a7d23af152ba5
(cherry picked from commit 5fbeff59df)
Instead of iterate all ellipsized characters, only iterate the necessary
ranges for copying.
Bug: 188913943
Test: atest CtsTextTestCases CtsGraphicsTestCases CtsWidgetTestCases
Change-Id: I3d03b1e3897e427c23fbe51315f412c57a4ce9e9
Merged-In: I3d03b1e3897e427c23fbe51315f412c57a4ce9e9
