* 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
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
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
Use a target background battery drain rate to determine the consumption
limit (stock).
Bug: 249365572
Test: atest frameworks/base/services/tests/mockingservicestests/src/com/android/server/tare
Test: atest frameworks/base/services/tests/servicestests/src/com/android/server/tare
Test: manually drain device and check calculation as it charges
Change-Id: I85879ed23365c388f2ff179c28973e8a2e72b827
This CL mechanically moves RemoteInputConnectionImpl from
com.android.internal.inputmethod
to
android.view.inputmethod
just to make it a package-private class, as it is (and should be) used
only by InputMethodManager.
This is a mechanical refactoring. There must be no developer
observable behavior change in this CL.
Bug: 192412909
Test: presubmit
Change-Id: I2d9bd4a5cb39d506a70331c9c930a74580cdbfa0
Root hash is only part of the fs-verity digest covers. Rename to avoid
confusion.
Bug: N/A
Test: m
Change-Id: I12c2a4ac57fb8772483473f951e97474ebd894c9
This CL makes it clear on how the following API works by renaming the
second boolean parameter to "implicitlyEnabledSubtypes".
InputMethodManager#getEnabledInputMethodSubtypeList(
@Nullable InputMethodInfo, boolean);
The second parameter controls whether the return value must contain
only explicitly enabled subtypes or not. Hence it is better to be
named as
"implicitlyEnabledSubtypes"
rather than
"implicitlySelectedSubtypes".
This is just a mechanical renaming. The must be no developer
observable behavior change.
Fix: 249648819
Test: presubmit
Change-Id: I7730f644435f4a2e0e88805744a5a43567ddf13b
While it still makes sense to require a user consent when enabling
non-system IMEs, programmatically modifying explicitly enabled
subtypes can be allowed for each IME as long as affected subtypes are
their own. This is why
IMM#setExplicitlyEnabledInputMethodSubtypes(String, int[])
is introduced in this CL. Here are use cases for IME developers.
* If they like, IME developers can take full control of what
subtypes are explicitly enabled for their IME, with their own
settings UI instead of relying on
InputMethodManager#showInputMethodAndSubtypeEnabler()
and user interactions. This also enables IME developers to
backup and restore enabled subtypes in some cloud services.
* If IME developers find that
Settings.Secure.ENABLED_INPUT_METHODS
contains any invalid subtype hashcode, or they plan to migrate
some legacy subtype hashcode to a new subtype hashcode, they can
programmatically fix/migrate it without bothering users.
See also the corresponding end-to-end test in CTS [1].
[1]: I0d46efb1ec98aaf529e2d531205ccd2cc0261492
Fix: 249110888
Test: atest CtsInputMethodTestCases:InputMethodSubtypeTest
Test: atest FrameworksServicesTests:InputMethodUtilsTest#updateEnabledImeStringTest
Change-Id: I836903dbdb6bc1ff3dc4b99710e4e08a65f59417
Already fixed in master via https://android-review.googlesource.com/c/platform/frameworks/base/+/2049443
This is that change, but in QPR.
Test: Share multiple images from photos, verify that edit button doesn't
appear.
Bug: 247638926
Merged-In: Id6ce93efacd54a86d870595ae32b4e6efcec0c04
Change-Id: I51b7d332b6b7e59ee559716022d795bb8de4a71c
Log the UI latency with UIActionLatencyReported atom. We plan to
calulate the latency from when the SoundTrigger HAL emits an event to
when the VoiceInteraction system UI view is shown.
Test: device_config put latency_tracker enabled true; verify traces
and latency is logged in WW.
Bug: 247879896
Change-Id: I3edb91691e81f8f23660c0823a6388338fe926ad
