This is the 6th CL for Bug 26851566 [1][2][3][4][5].
In the CLs [3][5], the approach we took was to extend an existing IPC
method
IInputMethodClient#setActive(boolean active, boolean fullscreen)
by adding one more parameter "reportToImeController".
However, it seems that such an approach made its handling code hard to
maintain, because the IPC method needed to behave in a completely
different manner depending on the newly introduced parameter.
To avoid such a confusion and to make subsequent refactoring easier,
this CL introduces a new IPC method
IInputMethodClient#setInteractive(
boolean interactive, boolean fullscreen)
to clarify what we are actually doing.
In most cases there must be no observable behavior change. One
possible behavior change is when setInteractive() gets called when
IMM#mCurRootView.getView() is not available. In the previous CL, we
fell back to previous behavior as if
FINISH_INPUT_NO_FALLBACK_CONNECTION was not defined. However it looks
like such a fallback mechanism is not an intentional behavior.
The main use case is still verified with existing CTS tests [6][7].
[1]: Ic11956fe745a829da1ec7c09ea214e9b3961c8e0
0df8812486
[2]: If06daf71160aa44a4254ac125561974ecbdef4f2
2c6e80be12
[3]: I8a657e75e274d842fb46b60375f6aeafeab96a59
152eacec4f
[4]: I16f4a34360a2f64b69978724648a9be741f140b5
3d62f739a8
[5]: Id4e71a822bfde5fe6a263bbe094c0d238017efe1
3d62f739a8
[6]: Iba0332ed3b767a9a15768b64947b9cde31105af1
e2f4138156c784746becde6a01c19f0c3de6ac32
[7]: I346ef42f2546a2925bf44ca7719ae19399e15e78
84c5ec2f81d4be5285b9c5f1d0e943f808e9158c
Bug: 26851566
Bug: 156215187
Test: atest InputMethodStartInputLifecycleTest
Change-Id: I0c95d7e70357ac98b336cd1b51a7405ba92a9a6f
This change implements PersistentServiceConnection and
ObservableServiceConnection helper classes in framework for better
handling of crashes.
Fixes: 247103878
Test: manually by crashing systemui using adb while dreaming and
verifying that the overlay is visible
Test: atest com.android.internal.util.PersistentServiceConnectionTest
Test: atest com.android.internal.util.ObservableServiceConnectionTest
Change-Id: Ib9a7e8675e408c1724567335a3c186fe5c9f5f59
This change implements PersistentServiceConnection and
ObservableServiceConnection helper classes in framework for better
handling of crashes.
Fixes: 247103878
Test: manually by crashing systemui using adb while dreaming and
verifying that the overlay is visible
Test: atest com.android.internal.util.PersistentServiceConnectionTest
Test: atest com.android.internal.util.ObservableServiceConnectionTest
Change-Id: Ib9a7e8675e408c1724567335a3c186fe5c9f5f59
Merged-In: Ib9a7e8675e408c1724567335a3c186fe5c9f5f59
* changes:
BroadcastQueue: periodic internal health check.
BroadcastQueue: mark dump methods @NeverCompile.
More tests for BroadcastRecord.
Relax broadcast ANR timeouts based on run_delay.
BroadcastQueue: more debugging information.
BroadcastQueue: add support for wait-for-barrier.
BroadcastQueue: add support for REPLACE_PENDING.
BroadcastQueue: add support for priority tranches.
Move direct-share icons loading off the main thread in the same way
we're loding A-Z icons.
Test: Manual testing with rotatin and screen locking, artificially
delaying image loading, debug logging for potential event loops.
Test: atest ChooserListAdapterTest
Fix: 215699869
Change-Id: I97e3383a74bb4ef795099fe55cae9fc5aed2b790
Change-Id: I3b110447d4cf2ab94e663c2684cd2cce4968d4ca
When the majority of CPU resources are being consumed by other
more-important tasks on the device, a broadcast receiver running at
a lower priority could end up triggering the ANR deadline due to
being starved for resources, which is unfair to that app.
This change relaxes the broadcast ANR timeout relative to the
amount of time a process was runnable-but-waiting, up to double the
normal ANR timeout.
Bug: 241829443
Test: atest FrameworksCoreTests:ProcessCpuTrackerTest
Test: atest FrameworksMockingServicesTests:BroadcastQueueTest
Test: atest FrameworksMockingServicesTests:BroadcastQueueModernImplTest
Change-Id: I903c3fa16e4bd64f1660bd0fb2f221b7b82f3661
This reverts commit 140516bf65.
Reason for revert: Bug where users cannot use biometrics to re-auth after trustagent timeout.
Bug: 251078638
Change-Id: I6254196327e09381eaa047e6444034ada6030113
This removes a race condition where ContentObserver is initialized
while mHandler is null which causes the ContentObserver#onChange() callback to run on a different thread and can cause an NPE.
Bug: 246843362
Test: manual
Test: atest BrightnessSynchronizerTest
Change-Id: Ib8e192c3961390ece721fa473d5c09323c30bafe
* changes:
Make the CE key always be encrypted by the synthetic password
Give all users SP-based credentials
Unlock user keys from LockSettingsService only
Make it so that every user gets a synthetic password (SP). Previously,
users only got an SP if an LSKF or escrow token was set at least once.
For normally created users, create the SP by making UserManagerService
call the new method LSS.createNewUser(), just after the prerequisite
steps of createUserKey and prepareUserData. As this now results in the
allocation of LSS state (e.g. a Weaver slot) before the user is fully
created, LSS can no longer rely on ACTION_USER_REMOVED for cleaning up
its state, so instead make UserManagerService.destroyUserState() call
LSS.removeUser(). Note that ACTION_USER_REMOVED isn't sent for
pre-created users, so as a side effect this change also fixes a bug
where LSS state for pre-created users wasn't removed immediately.
For the system user, which doesn't go through the normal user creation
flow, make LSS create the SP upon PHASE_BOOT_COMPLETED. At the same
time, also create SPs for any other users who don't have one yet; this
handles users that were created by older versions of Android.
This change makes things more consistent. It is also a prerequisite to
making it so that a Weaver value is always needed to unlock the CE key
if the device supports Weaver; this is important since Weaver may be the
only available securely erasable storage. A later CL will implement
this by making the CE key be always bound to the SP. For now, the CE
key remains unlockable separately from the SP when there is no LSKF.
Test: see Ia753ea21bbaca8ef7a90c03fe73b66c896b1536e
Bug: 232452368
Change-Id: Ic82084fe9d9bb34ee9640dea027963043afca9c2
In preparation for making the CE key of each user always be protected by
the user's synthetic password even when the user has no LSKF, make
LockSettingsService the sole caller of IStorageManager.unlockUserKey().
For the opportunistic secret-less unlock by UserController at user start
time, call a new method LSS.unlockUserKeyIfUnsecured(). For now this
method calls IStorageManager.unlockUserKey() with a null secret. Later
it will unwrap the user's synthetic password if needed.
For the unlock via credential verification that is triggered by LSS,
make LSS call IStorageManager.unlockUserKey() before calling
IActivityManager.unlockUser(), rather than passing the SP-derived secret
to IActivityManager.unlockUser() for it to do the unlockUserKey().
Since neither the secret nor the token arguments to
IActivityManager.unlockUser() are used anymore, add a new method
IActivityManager.unlockUser2() that lacks these arguments. Note that
method name overloading cannot be used because AIDL doesn't support it.
Test: atest com.android.server.locksettings && \
atest com.android.server.am.UserControllerTest \
com.android.server.pm.UserManagerServiceTest \
com.android.server.pm.UserManagerTest
Test: Boot and reboot Cuttlefish
Bug: 232452368
Change-Id: I8971b92bb5055fca8e19e0f9d14e8f0a7022b453
Complete the change in ag/19657256 to also apply in SelectableTargetInfo.
That would ensure that in all cases of cross-profile targets the URIs
are fixed to include the user-id prefix.
Bug:244876518
Bug:242605257
Test: manually share image from work Photos app to personal WhatsApp's
frequent contact target.
Change-Id: Ib41c8a3c46afcc2d62a4c1a924212bcd98bcfbe4
The current implementation triggers icon loading each time a view gets
bound and, as binding happens multiple times, icon and label loadings
are unnecessarily duplicated. In addition, as a loading task never gets
canceled, there’re cases (like in the associated ticket) when a view
gets rapidly bound to multiple positions and all the icon loadings
eventually catches up updating it, ending up in icons rapidly changing
on the screen for the view.
This change addresses this by simplifying the icon loading/binding
logic: a view is always bound to the current data and the task is only
updates the data with the missing piece of info once (and applied for
both icons and label loading tasks).
There is one extra change in ResolverActivity due to LoadIconTask
interface change and cancellation logic for the tasks.
Fix: 245934835
Test: Manual tests on a list which does not fit into the screen.
Test: Manual tests with arficial delays added into the tasks.
Test: atest FrameworksCoreTests:ResolverActivityTest
Test: atest FrameworksCoreTests:ChooserActivityTest
Change-Id: I76fe5663523232a74d4f505c535cd6dbcf7f8759
Adds a new ResolverDrawerLayout XML property, ignoreOffsetTopLimit, that
takes a direct child view’s id. The specified view will serve as a top
limit for all child views below it with layout_ignoreOffset attribute
set to true i.e. they will be pushed down by the view when the drawer
is moving.
Fix: 240481385
Test: atest FrameworksCoreTests:ResolverActivityTest
Test: atest FrameworksCoreTests:ChooserActivityTest
Test: Manual testing with some injected code that simulates various
conditions:
* various property values or property absence
* simultaneous layout and drawer moving
* one-time layout while an "ignoreOffset" view has been moved out of
place with a consequent release.
Change-Id: Ib9aa4f11d35c2dede06b0913091e7b146438e57e
This is a follow up CL to my previous CL [1], which locked down
IInputMethodManager#isInputMethodPickerShownForTest()
with
android.Manifest.permission.TEST_INPUT_METHOD
permission.
After the original CL was committed the severity assessment was
performed again and in the updated assessment it was concluded that
denial logging was not necessary. With that, this CL simplifies the
logic by using
@EnforcePermission
annotation in the ADIL method definition.
Note that there must be no developer-observable behavior change in
this CL, and the security test that was added as part of the original
effort [2] still verifies that the method in question is indeed
guarded with "TEST_INPUT_METHOD" permission.
[1]: Ie79a3e9d41ce22605ae083594d639c37d08b7def
b869c78380
[2]: Idf907e3b762307696a3a7ca11470b0c44b9b7aa4
3e1dd9d2797f818766105247e3634da525fec8e8
Bug: 237317525
Test: atest CtsInputMethodTestCases:InputMethodManagerTest#testIsInputMethodPickerShownProtection
Change-Id: Ib3f56b1ab1538742a2bf64fec435ced5b8f90bc2
