Hopefully no one has relied on this undocumented behavior that when
the caller has WRITE_SECURE_SETTINGS then null IME token is allowed in
IMM#switchToLastInputMethod().
Bug: 114488811
Test: CtsInputMethodServiceHostTestCases
Change-Id: Icb02c9bb52b11cff39b222198f4b67984676b9a6
It turns out that we had already rejected null IME token in
InputMethodManager#switchToNextInputMethod() since Android L [1].
Hence there is no need to keep this IPC any more.
There should be no developer-visible behavior change.
[1]: I043aa30a19c821f33effd57dfd6590b0e3ed817b
34c666472137a99a2ce5546b80bd04979d10ab7a
Bug: 114488811
Test: atest CtsInputMethodServiceHostTestCases
Change-Id: I72ee82d62e3bdce44f623604eca86ab3fe3df0bd
When setting a password from DPM.resetPassword(), the actual quality of the
password was not passed to LockSettingsService (instead, the minimum required
quality was passed which is often UNSPECIFIED). As a result, during FRP we
would see inconsistent state and skip it.
Bug: 110172241
Test: Set credential via DPM.resetPassword(), factory reset device to trigger FRP, verify FRP shows.
Change-Id: I54376f60ac53451ace22965d331b47cd8c2e614e
- Set ThreadLocalWorkSource to the work source uid when app has the
UPDATE_DEVICE_STATS permission. We only enable that in system server for
now.
- By default, set ThreadLocalWorkSource to the calling uid since we
always trust this value.
- If an app sets a work source uid without having the right permission,
we just ignore it (we do not throw an exception)
A follow-up commit will update the code to use the worksource from the
beginning of the call. Currently we get the work source at the end
inside of BinderCallStats, however the value might have been changed
when executing onTransact.
Test: atest binderLibTest BinderWorkSourceTest BinderCallsStatsServiceTest
Change-Id: I351b8ac2b31feececc46c73f373f198b9b603c7e
In this CL, we add parameter displayId in some IStatusBar APIs and also
group flags into an inner class and make it exist per display.
TODO: 1. We left SystemUi implementation in later CL.
2. Investigate which part of disable should support multi-display
after main function completes.
3. Refactor registerStatusBar as an IStatusBar API.
Note: remove mLightsOutListener in NavigationBarTransitions since no one uses it.
Test: atest SystemUITests
Bug: 117478341
Change-Id: Ie50a72f5d18e1f055ff2be4f1d7ac06da0117051
Binder/Looper stats data is collected only when the device
is on battery. Adding the time on battery to dumpsys output
will make it easier to analize the data.
Test: UT and manually checked dumpsys output
Change-Id: I0536e718399181cb62f5de6bbd24a6fb73c26e7e
Fixes: 120092266
Test: - install apk https://drive.google.com/file/d/1eh2mCz-0Ymm4TghOaf46ZHdn2-M8bm6i/view?usp=sharing
- hardcode DefaultPermissionGrantPolicy to always run on reboot
- adb reboot
- ensure device bootloobs with an error from attached bug
- apply fix
- ensure device no longer bootloops
- ensure no error in logcat
Change-Id: If2387e963b63231b0b99a55fdb7e75187d07bd07
Inline image will consume 3x memory due to no cache implementation.
This patch apply cache mechanism to each ExpandableNotificationRow and
preloads images before inflation task.
Bug: 77956056
Test: runtest systemui, observe memory usage by AndroidProfiler
Change-Id: I2c488b1d98ddf2d4670904ed4b3e8028c0d0172e
Implements basic API's to control windows generating insets in
the new insets world.
Test: CTS tests will be added at some point in the future
Bug: 118118435
Change-Id: I722d2e58c68734ac131b12da3d9978e946292130
This logic will ensure that we have a limit for the number of items we
track to make sure we do not use too much memory.
We still have an overflow per uid in order to properly attribute the cpu
usage to the uids.
Test: atest BinderCallsStatsTest
Change-Id: Ife9f7249bae35d5c61a6d35ac9d25437d213e959
Change 1/2. Change 2/2 will setup the class loader namespace for
shared libraries.
This change sets up shared libraries class loaders for applications
and for dexopt.
bug: 111174995
Test: DexoptUtilsTest, device boots
Exempt-From-Owner-Approval: PS1 was approved by owner, PS2 is a build fix.
(cherry picked from commit 8d144eb8bd)
Merged-In: Ie9a2b4eaa85cda59951703433f7a2d03bc12095d
Change-Id: I76383308418485ad6739f8a404d02c2771e4afe4
Test: Manualy launch an app
Test: Press home when activity is on top of the stack
Test: Quick scrub
Test: Swipe up on the home button, swipe down
Test: Tap on notification on the shade
Test: atest ActivityLaunchAnimatorTest
Bug: 111514493
Change-Id: Ib7e29e7e07bf2a245ff949373af700b319e273fc
The existing appendWhere() methods aren't very friendly for
developers, since they require manual tracking of state to decide if
subsequent standalone chunks should be prefixed with "AND".
While it's tempting to offer direct argument binding on the builder
class, we can't really deliver on that API in a secure way, so instead
add separate bindSelection() method which explicitly burns arguments
into a standalone selection string, which can then be appended to
the builder.
This was the last piece of new functionality being used by
SQLiteStatementBuilder, so we can delete that class and migrate
users back to SQLiteQueryBuilder.
Bug: 111268862
Test: atest frameworks/base/core/tests/coretests/src/android/database/DatabaseUtilsTest.java
Test: atest frameworks/base/core/tests/utiltests/src/com/android/internal/util/ArrayUtilsTest.java
Test: atest cts/tests/tests/provider/src/android/provider/cts/MediaStore*
Test: atest cts/tests/tests/database/src/android/database/sqlite/cts/SQLiteQueryBuilderTest.java
Merged-In: I418f24338c90bae8a9dad473fa76329cea00a8c5
Change-Id: I418f24338c90bae8a9dad473fa76329cea00a8c5
Developers often accept selection clauses from untrusted code, and
SQLiteQueryBuilder already supports a "strict" mode to help catch
SQL injection attacks. This change extends the builder to support
update() and delete() calls, so that we can help secure those
selection clauses too.
Extend it to support selection arguments being provided when
appending appendWhere() clauses, meaning developers no longer need
to manually track their local selection arguments along with
remote arguments.
Extend it to support newer ContentProvider.query() variant that
accepts "Bundle queryArgs", and have all query() callers flow
through that common code path. (This paves the way for a future
CL that will offer to gracefully extract non-WHERE clauses that
callers have tried smashing into their selections.)
Updates ContentValues to internally use more efficient ArrayMap.
Bug: 111268862
Test: atest frameworks/base/core/tests/utiltests/src/com/android/internal/util/ArrayUtilsTest.java
Test: atest cts/tests/tests/database/src/android/database/sqlite/cts/SQLiteQueryBuilderTest.java
Merged-In: I60b6f69045766bb28d2f21a32c120ec8c383b917
Change-Id: I60b6f69045766bb28d2f21a32c120ec8c383b917
* changes:
3/n: For passive modalities, add plumbing for "try again"
2/n: Multi-modal support for BiometricPrompt
1/n: Move BiometricDialog management to BiometricService
When "try again" is showing, authentication is canceled internally.
BiometricService caches the client's info so that authentication can
be restarted when "try again" is pressed. Because authentication
is not running when "try again" is showing, BiometricService also needs
to have a TaskStackListener so that BP can be dismissed and an error can
be sent to the client when the app loses focus.
IBiometricServiceReceiver has been split into two. One for BiometricPrompt
to receive messages from BiometricService, and another for BiometricService
to receive messages from SystemUI/<Biometric>Services.
When we get locked out, don't send the last onAuthenticationFailed
to the client, since "Authentication failed" will be shown briefly
and be replaced by "Device locked out" which is janky
Bug: 111461540
Test: Tested with requireConfirmation enabled/disabled
Test: Tested onConfigurationChange corner cases, e.g. when "try again"
or "confirm" buttons are showing, rotate the device. Buttons
persist correctly and don't appear when unexpected
Test: Tested task stack corner cases, e.g. when "try again" is showing,
press home button. BP dismisses and client receives ERROR_CANCELED
Test: BiometricPromptDemo receives all callbacks
Change-Id: I62126708ce8db8b358c666a07aa7c39607642c9d
This computes and stores a hash of significant (for PermissionController)
packages state for the time when granting last ran.
Test: - enable DEBUG flag
- using logcat ensure roles granted on first bootloader
- adb reboot
- ensure roles granting skipped
- disable a package
- adb reboot
- ensure roles granting ran on boot
Change-Id: Idaea40c0ea34feaedfbe357627201f85e66876d5
Mostly designed for use by tests, but start using it elsewhere in OS
for consistency.
Bug: 119713234
Test: manual
Change-Id: I803671fd84547b75337bebf00c2fa2bdaf0f72e7
Since not all KEYCODE_MEDIA_* keycodes return true in isMediaKey(),
the naming can give confusion. This CL renames the method to
isMediaSessionKey() and revises its Javadoc.
Bug: 119789707
Test: make -j
Change-Id: I36786ccf5606977e6d971c13d77d950356561bda
This CL starts a journey to discover a brave new inset world. The
path to get us there may be rocky, but it's going to be rocky.
One of the main pledges of the new API is that an app can retrieve
what is causing a certain inset easily. For that, we need to
dispatch metadata who is causing what inset, such that we can query
it from the client side.
Furthermore, the client will be able to manipulate insets directly,
but also listen to animation changes. We don't want to go through
window manager for that, thus, there needs to be a local codepath
from (global window state -> WindowInsets).
Because we have these two requirements, we dispatch the relevant
global window state for insets, represented by InsetsState, and
dispatch it to the client. On the client side we take the frame
and the InsetsState and generate WindowInsets out of it.
Bug: 118118435
Test: InsetsSourceTest, InsetsStateTest, InsetsSourceProviderTest,
InsetsStateControllerTest
Change-Id: I2bfe9dda376512916261823fc2ee35cbedeb6731
This is added to report clicks on actions buttons to NAS.
BUG: 119010281
Test: atest SystemUITests
Test: atest RemoteViewsTest
Test: atest NotificationManagerServiceTest
Test: Manual. Tapped on the action (both normal and contextual) and
observed the log.
Change-Id: I381994737d8c3185d3fabf9b6c481fd01a89a634
The BiometricDialog management was done in AuthenticationClient, but
this is not great for the following reasons
1) The dialog lifecycle should not be 1:1 tied to the client monitor,
since this restricts flexibility
2) Devices with multiple biometrics implemented on BiometricDialog
will require extra work. Moving the dialog management up one layer
should solve this limitation
BiometricService now sends both its own receiver and the client's receiver
to the appropriate <Biometric>Service. When the client is actually started
by the <Biometric>Service, it will forward the client's (BiometricPrompt's)
receiver to BiometricService. Lifecycle management is currently still in
<Biometric>Service since the platform still uses <Biometric>Service
directly. AuthenticationClient for BP is now started with the wrapper
receiver, which allows BiometricService to handle messages before deciding
if it should forward the message to the client.
Moving lifecycle management to BiometricService is currently not a great
idea since framework doesn't always go through BiometricService.
Also merged IBiometricPromptReceiver with IBiometricServiceReceiver
Bug: 111461540
Test: Negative button works (error received by demo app)
Test: Cancelling via back or tapping gray area works (error received
by demo app), and hardware is no longer authenticating
Test: Dismissing BP via negative button or gray area returns only a single
error and is not followed by ERROR_CANCELED (as expected)
Test: Error messages are delayed when BP is showing, not delayed
when BP is not showing (pre-auth check errors e.g. no hardware)
Test: Lockout works
Test: Lockout counter resets upon successful auth
Test: Keys are unlocked properly for both implicit and explicit modes
TODO: Figure out multi-modal BiometricService / <Biometric>Service
synchronization. Likely we keep the bundle in BiometricService
and send random numbers (identifier) to <Biometric>Service. When
each <Biometric>Service is ready, it should return the number. Once
BiometricService receives all identifiers, it can then notify
all <Biometric>Service to start authenticating.
Change-Id: I2b6fa57ed3c3cbccc7b0be30279f80fa46a8e917
