Test: wake up with power
Test: look at shelf on lock screen
Test: lock device w/ notifications from home screen
Test: receive notification on AOD
Test: atest KeyguardClockPositionAlgorithmTest
Test: atest NotificationRoundnessManagerTest
Test: atest ScrimControllerTest
Test: atest NotificationContentViewTest
Bug: 111405682
Change-Id: I9b4f2febd56a62256124567bffebc9f5f8255847
This is a follow up CL to our previous CL [1], which enabled spell
checker for background users. In that CL, we assumed that spell
checker user ID can and should always be determined by the calling
user ID. This assumption is not valid at least for direct-reply
notifications on System UI, because System UI always runs as user 0 no
matter who is the current active user.
In order to allow TextServicesManagerService (TSMS) connect to the
right user for such a special use case, this CL introduces a hidden
parameter "userId" to each IPC so that clients that have
INTERACT_ACROSS_USERS_FULL can override the target user ID when
necessary.
For instance, to interact with user 10's spell checker services, you
can obrain a special instance of TextServicesManager as follows.
TextServicesManager tsmForUser10 = context
.createPackageContextAsUser("android", 0, 10 /* userId */)
.getSystemService(TextServicesManager.class)
If the calling process does not belong to user 10, any operations on
that TextServicesManager will result in SecurityException unless the
calling package needs to have INTERACT_ACROSS_USERS_FULL.
This CL is just a preparation. There should be no user-visible
behavior change yet.
[1]: I06c27ef834203a21cc445dc126602c799384527b
06a2624049
Bug: 123043618
Test: spell checker still works
Change-Id: I31dda3ae8795190d44b0622b8335c34ddbc5dd48
DEVICE_SHUTDOWN event is used to close all open usage events that do
not have matching closing event when device is shut down. For example,
ACTIVITY_RESUMED or FOREGROUND_SERVICE_START are open events, the
DEVICE_SHUTDOWN event will close the usage session of the open events.
At orderly shutdown like selecting Power Off or Restart after pressing
power button, a DEVICE_SHUTDOWN event is sent to UsageStats.
UsageStats persists UsageStatsDatabase to disk immediately.
When power button is pressed for 3.5 seconds (configured by
config_veryLongPressTimeout in config.xml). A DEVICE_SHUTDOWN
event is sent to UsageStats. UsageStats persists UsageStatsDatabase
to disk immediately.
This is the mechanism that we do not lose UsageStats data when the
device is shut down.
When the device boots up, if the last event is not
DEVICE_SHUTDOWN, we add a DEVICE_SHUTDOWN with timestamp set to be the last
time database file is persisted. This is to handle the case device
shutdown abruptly due to power drained or cold temperature.
Bug: 111464278
Test: atest UsageStatsTest.java
Change-Id: I1e88063ba71d09042d02c6deb9f07d8581a15c30
The previous check was disabling it for "non-system" apps that were bundled
in the system...
Bug: 121045049
Fixes: 122915433
Test: manual verification
Test: atest CtsAutoFillServiceTestCases
Change-Id: I2352fc21de27750509715035ba2f9c2dc2371428
Also updated documentation and added the relevant test.
Bug: 122887441
Test: atest com.android.server.pm.UserManagerTest#testSwitchUserByHandle_ThrowsException
Change-Id: Ic936570ff24d4879732017c717d8c81f38356553
* BubbleMetadata encapsulates necessary info to display a bubble
* Replaces app overlay intent usages with BubbleMetadata
* Renames existing bubble APIs to use 'bubble' rather than 'app overlay'
Bug: 111236845
Test: existing tests pass
Change-Id: I6a85d3c41dda47139fb8d960cadf1c8e109cf29b
1. The book-keeping needs to be per user.
2. The calls into IBackupManager need to pass in the userId.
3. convert clearPendingBackup to an internal service call.
Bug: 121197004
Test: 1) atest RunBackupFrameworksServicesRoboTests
2) atest $(find \
frameworks/base/services/tests/servicestests/src/com/android/server/backup \
-name '*Test.java')
3) atest CtsBackupTestCases
4) atest CtsBackupHostTestCases
5) 'adb shell bmgr' enabled/backupnow flow
Change-Id: If49e00fc1d6aa770815c454f01b53865f6a68db4
This change adds Intent.ACTION_MANAGE_DEFAULT_APP and
Intent.EXTRA_ROLE_NAME for managing a single default app, which will
be launched from Settings' App info page. The new
Intent.EXTRA_ROLE_NAME also replaces RoleManager.REQUEST_ROLE_NAME.
Bug: 110557011
Test: build
Change-Id: Ice81150b0e960d050d24d963ade04254852a4ee4
Test: atest, make sure missed call notifications are no
longer demoted by aosp notification assistant
Change-Id: I80728bae67501d64359e0dac02dca928c34a7e95
Fixes: 122657004
Let an activity show on top of the lock screen if the activity behind
this can be shown on top of the screen. This is pre-requisite for
showing permission dialog on top of the lock screen only when it makes
sence.
Bug: 109754623
Test: atest server.am.KeyguardTests
Change-Id: Ideaa2b77519649a70c682bc95277e451e149adad
Test: builds and tested in local theme picker
Bug: 121328713
Commands executed:
$ make system-api-stubs-docs-update-current-api
$ make api-stubs-docs-update-current-api
Cts tests to follow
Change-Id: Id26d32f482c1bbab3497b517b7a553d145a1e3df
Signed-off-by: Hyunyoung Song <hyunyoungs@google.com>
This change adds the names of the home and emergency roles, which will
be used by Settings.
Bug: 110557011
Test: build
Change-Id: I40bb0e021232acff62a32e0bdc24a04ff9ec6ba8
In order to support BYOD (Bring your own device) use cases, Android
phones can associate multiple users into a single profile group so
that other system components such as launcher can help users
seamlessly switch user identity without doing a heavy-weight
device-level user switching.
For instance, an Android device can be configured to work for two
different users Alice and Bob, while Alice also has two different
identities: one as her private account and the other for her
work-related account.
Profile group X == Alice:
Parent user X (user id: 0)
for personal account, under her control.
Child user 1 (user id: 10)
for work-related account, partly under system-admin's control.
Profile group Y == Bob:
Parent user Y (user id: 11)
private account, under his control.
The above configuration allows system-level data separation not only
between Alice (user 0) and Bob (user 11) but also between Alice's
personal account (user 0) and Alice's work-related account
(user 10). For instance, Calendar app that runs under user 0 cannot
see any data for other users including user 10.
IME is one of known exceptions in the above design. For instance, when
Alice is using the device, the system launches InputMethodService,
which is the code-level representation of IMEs, only for the user 0
then gives it a special ability to interact with all the applications
that run under the same profile group.
Profile group X == Alice:
IME works as user 0 but interacts with apps that run under
user 0 and 10.
Profile group Y == Bob:
IME works as user 11 and interacts with apps that run under
user 11.
Of course there are non-trivial imprications by sharing the same
instance of InputMethodService across profiles but this was basically
the only option when we initially introduced in Android 5.0 [1]
because of multiple challenges (schedule, complexity, performance
concerns, and so on). To to mitigate the risk, we also introduced APIs
that allow system administrators to whitelist what IMEs can be enabled
for the entire profile [2]. Even with such a whitelist feature, we
have received multiple feature requests to completely separate IME
instances by profile boundaries, like other applications behave.
This is why this CL was authored.
With this CL, a new runtime mode "per-profile IME" is introduced
behind the flag. When the flag is enabled:
* InputMethodManagerService (IMMS) may calls IMMS#switchUserLocked()
from IMMS#startInputOrWindowGainedFocus() every time when a
different profile's IME client gains IME focus.
* SpellCheckerService also enables per-user mode, which has been
temporarily disabled [3].
* DevicePolicyManagerService no longer disable packages that contain
system IMEs when creating a new profile user.
* Following IME APIs start returning result based on the caller's
user (profile) ID.
* InputMethodManager#getInputMethodList()
* InputMethodManager#getEnabledInputMethodList()
* InputMethodManager#getEnabledInputMethodSubtypeList()
There are still multiple known issues though. Hopefully we can address
those issues in subsequent CLs.
* Inline-reply from non-primary profiles is still dispatched to the
main profile's IME because SysUI is always running under main
profile (Bug 120744418). This probably can be addressed by
allowing the IME clients that have INTERACT_ACROSS_USERS_FULL to
specify the target user ID in some @hide parameter.
* IMMS#switchUserLocked() is not yet fully optimized (Bug 28750507).
New client app's UI thread can be blocked more than 100ms,
depending on the number of installed IMEs and the number of IME
subtypes implemented by those IMEs.
* Even after IMMS#switchUserLocked() is fully optimized, IMEs'
cold-startups are known to be slow. One way to optimize this is
keeping binding to those IMEs, but doing so would require 1)
non-trivial amount of code changes and 2) doubles RAM consumption.
* Virtual keyboard settings page for profile users are not yet
available (Bug 120748696).
* Migration from shared-profile IME mode to per-profile IME mode is
not yet supported (Bug 121348796). By default, IME packages will
be automatically disabled when a profile user is created. This
means if the device switches from shared-profile IME mode to
per-profile IME mode, IME packages continue to be disabled hence
the user cannot type anything for those profiles.
Anyway, there should be no behavior change unless the debug flag is
explicitly flipped.
[1]: I3bd87b32aec69c3f8d470c8b29b144f4e849c808
734983fff3
[2]: I921888660d29a5370395db87adf75d4d106660c9
9c9cbac5b71a23ed0dbab0f44cb78a820514cfc6
[3]: Ic046f832f203115106409a53418a5746eb6d4939
3f8c568883
Fix: 120709962
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Test: Made sure that there is no behavior change if the debug flag is
not set as follows.
1. Install Test DPC
2. Enable managed profile with Test DPC
3. make -j EditTextVariations
4. adb install -r $ANDROID_TARGET_OUT_TESTCASES/EditTextVariations/EditTextVariations.apk
5. Open two EditTextVariations instances in split-screen mode
5.1. One is for the main profile
5.2. The other is for the managed profile
6. Make sure that main profile's instance of AOSP Keyboard is used
for both applications.
7. Make sure that main profile's instance of Android Spell Checker
is used for both applications.
8. adb shell ime list -a -s --user all
-> Only "com.android.inputmethod.latin/.LatinIME" is shown.
9. adb shell dumpsys textservices
-> Only result for user #0 is shown.
Test: Made sure that basic text input can be done with
"per-profile IME" mode enabled as follows.
1. adb root
2. adb shell setprop persist.debug.per_profile_ime 1
3. adb reboot
4. Install Test DPC
5. Enable managed profile with Test DPC
6. make -j EditTextVariations
7. adb install -r $ANDROID_TARGET_OUT_TESTCASES/EditTextVariations/EditTextVariations.apk
8. Open two EditTextVariations instances in split-screen mode
8.1. One is for the main profile
8.2. The other is for the managed profile
9. Make sure that AOSP Keyboard will be re-launched to correspond to
the focused IME client's user profile.
9.1 When EditTextVariations for the main profile is focused,
AOSP Keyboard for the main profile is shown.
9.2 When EditTextVariations for the work profile is focused,
AOSP Keyboard for the work profile is shown.
10. Make sure that different instances of Android Spell Checker are
used based on target application's profile
11. adb shell ime list -a -s --user all
-> "com.android.inputmethod.latin/.LatinIME" is shown for both
user #0 and user #10.
12. adb shell dumpsys textservices
-> Both user #0 and user #10 have results.
Test: atest DevicePolicyManagerTest#testSetPermittedInputMethods_failIfNotProfileOwner
Test: atest com.android.server.devicepolicy.OverlayPackagesProviderTest
Change-Id: Ied99664d3dc61b97c919b220c601f90b29761b96
This change is the main check in for the historical app op feature.
The idea is to store a historical data about past app op rejections,
accesses, and durations per op for any UID state indefinitely.
Keeping all operations on record is not practical as app ops are
very frequently performed. To address this we are storing aggregated
data as snapshots where we store for every UID and its packages
how many times each op was accessed, rejected, lasted as an aggregate.
To allow history scaling indefinitely we are taking a logarithmic
approach with only the most recent state stored in memory and all
preceding state stored on disk. State on disk is stored in separate
files where each preceding file, i.e. for an older period, would
cover X times longer period with X number of snapshots covering
X times longer period. Initially X is ten but can be tweaked. For
example, the first file could contain data for ten days with daily
snapshots, while the file for older period would have data
for a hundred days with snapshots every ten days, etc.
The implementation is optimized for fast history update and no impact
on system runtime performance and minimizing memory footprint. We
are lazily persisting state to disk on a dedicated thread as this is
slow. We are also reading the relevant historical files on a query
as this is very rare as opposed to state updates.
The base snapshot interval, i.e. snapshot time span, in the initial
iteration and the logarithmic step are configurable. These can be
changed dynamically and the history would be rewriten to take this
into account.
Test: atest CtsAppOpsTestCases
bug:111061782
Change-Id: I55c32c79911ba12b2ace58d2a782b8df1e6bff60
Adding a package manager api to mark packages as distracting to the
user. While doing this, some restrictions can be imposed on these
packages to enable the user to refrain from using them often.
Test: Unit tests:
atest com.android.server.pm.PackageManagerSettingsTests\
com.android.server.pm.PackageUserStateTest
GTS test: atest GtsSuspendAppsTestCases
Bug: 117407613
Change-Id: I5d0606b3c6c1edcaba001852d10f1a9e140b8028
This CL introduces sequence number to activity configurations and use
that to compare their staleness. Always use the last reported activity
configs for Activity#onConfigurationChanged() and drop all requests
that are older than the processed one.
Fixes: 120189873
Test: Manually verify that number of configuration changes drops during
drag-resizing with a crafted app that needs 250ms to perform one
configuration change. go/wm-smoke too.
atest FrameworksCoreTests:ActivityThreadTest
atest WmTests:ActivityRecordTests
Change-Id: Ie0fd15458517470542a689b51283f4d1ed2ad4cc
This includes laying down some groundwork to make the remaining migrations
more straightforward
Bug: 110557011
Test: atest RoleManagerTest && atest SmsManagerTest
Change-Id: Ie96abd73751d10f521756c9dcdab2a5710ca2045
