After an app publishes a shortcut that contains malformed intent, the
system can be stuck in boot-loop due to uncaught exception caused by
parsing the malformed intent.
This CL ignores that particular malformed entry. Since shortcuts are
constantly writes back into the xml from system memory, the malformed
entry will be removed from the xml the next time system persists
shortcuts from memory to file system.
Bug: 246540168
Change-Id: Ie1e39005a5f9d8038bd703a5bc845779c2f46e94
Test: manual
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 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 will prevent bouncer interactions from showing up in
screenrecords or screenshots.
Fixes: 215005011
Test: atest StatusBarWindowControllerTest && take screenshot
with bouncer up
Merged-In: I3f59df865dc2dd13d4b9ac54bb2dacb7b23f0aa1
Change-Id: I8df2258863b8cede5ba112331e0446f534267ba2
After PUK unlock, multiple calls to
KeyguardSecurityContainerController#dismiss() were being called from
the KeyguardSimPukViewController, which begins the transition to the
next security screen, if any. At the same time, other parts of the
system, also listening to SIM events, recognize the PUK unlock and
call KeyguardSecurityContainer#showSecurityScreen, which updates which
security method comes next. After boot, this should be one of PIN,
Password, Pattern, assuming they have a security method. If one of the
first dismiss() calls comes AFTER the security method changes, this is
incorrectly recognized by the code as a successful
PIN/pattern/password unlock. This causes the keyguard to be marked as
done, causing screen flickers and incorrect system state.
The solution: every call to dismiss() should include a new parameter
for the security method used. If there is a difference between this
parameter and the current value in KeyguardSecurityContainerCallback,
ignore the request, as the system state has changed.
Bug: 218500036
Test: atest KeyguardSecurityContainerTest
Merged-In: I7c8714a177bc85fbce92f6e8fe911f74ca2ac243
Change-Id: I30226bc7b5eda9480d471b35fe81e106b0491ff8
This will prevent bouncer interactions from showing up in
screenrecords or screenshots.
Fixes: 215005011
Test: atest NotificationShadeWindowControllerImpl && take screenshot
with bouncer up
Merged-In: I3f59df865dc2dd13d4b9ac54bb2dacb7b23f0aa1
Change-Id: Icde7849a181ce8e0c1074537f6dde897aedd8bb3
After PUK unlock, multiple calls to
KeyguardSecurityContainerController#dismiss() were being called from
the KeyguardSimPukViewController, which begins the transition to the
next security screen, if any. At the same time, other parts of the
system, also listening to SIM events, recognize the PUK unlock and
call KeyguardSecurityContainer#showSecurityScreen, which updates which
security method comes next. After boot, this should be one of PIN,
Password, Pattern, assuming they have a security method. If one of the
first dismiss() calls comes AFTER the security method changes, this is
incorrectly recognized by the code as a successful
PIN/pattern/password unlock. This causes the keyguard to be marked as
done, causing screen flickers and incorrect system state.
The solution: every call to dismiss() should include a new parameter
for the security method used. If there is a difference between this
parameter and the current value in KeyguardSecurityContainerCallback,
ignore the request, as the system state has changed.
Bug: 218500036
Test: atest KeyguardSecurityContainerTest
Merged-In: I7c8714a177bc85fbce92f6e8fe911f74ca2ac243
Change-Id: I30226bc7b5eda9480d471b35fe81e106b0491ff8
Any malicious application could hijack tasks by
android:allowTaskReparenting. This vulnerability can perform UI
spoofing or spying on user’s activities.
This CL only allows activities to be reparent while
android:allowTaskReparenting is applied and the affinity of activity
is same with the target task.
Bug: 240663194
Test: atest IntentTests
Change-Id: I73abb9ec05af95bc14f887ae825a9ada9600f771
BUG: 242996180
Test: adb shell pm uninstall --user 0 com.google.android.apps.work.oobconfig
Test: Verified with the command above. Before this CL, the package can
be deleted. After this CL, the deletion will fail.
Change-Id: Iba408e536b340ea5d66ab499442c0c4f828fa36f
(cherry picked from commit 15f85c7fa9)
Merged-In: Iba408e536b340ea5d66ab499442c0c4f828fa36f
BUG: 242996180
Test: adb shell pm uninstall --user 0 com.google.android.apps.work.oobconfig
Test: Verified with the command above. Before this CL, the package can
be deleted. After this CL, the deletion will fail.
Change-Id: Iba408e536b340ea5d66ab499442c0c4f828fa36f
(cherry picked from commit 15f85c7fa9)
Merged-In: Iba408e536b340ea5d66ab499442c0c4f828fa36f
This reverts commit ff7be9912f.
Reason for revert: b/241798893. Note: this fix is not the root cause of the breakage. It just exposes a previously unknown bug. See linked bug.
Change-Id: I7da45dfedace793085da06697976d189e8e7fbdb
Merged-In: Ibabff26c5a54e89c5dbe3a577f4c7739be6e2709
