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
* 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
The API is mostly implemented; except for hooking up the listener
and handling an already running bugreport.
BugreportManager is the handle to the new API exposed to apps.
Generating bugreports requires root privileges. To limit the footprint
of the root access, the actual bugreport generation in Dumpstate binary,
is accessed as a oneshot service and dies after it finishes
running.
System server accesses Dumpstate via a binder interface since it does
not have root privileges.
Starting a oneshot service is done via setting a system property, which
needs to be done from system server. BugreportManagerService is the
new system server service that does this. BugreportManager calls into
BugreportManagerService via a binder interface, since the former is in
the app's process.
Both app to system server as well as system server to native service
calls are via implementations of IDumpstate binder interface.
Bug: 111441001
Test: builds. Flashed & verified it boots.
Test: wrote a test client (not included) and verified invoking
startBugreport works.
Change-Id: I4abeb753388c055c36ae0dd916af1ec8d40b7bf0
when service-based PendingIntent was whitelisted
Extends the mechanism added for broadcasts in ag/5779089.
The process can start activity from background when whitelisted
PendingIntent-based Service was started - for the next 10 seconds,
or until the service is stopped, whichever happens sooner.
For now, all this is only wired for notifications.
Bug: 110956953
Test: atest WmTests:ActivityStarterTests
Test: manual with Calendar notifications that are known
for doing Service trampolines
Change-Id: If6ed2f5e22403c4df5abb6cf876ae89505e57380
Making color hint's relative api @SystemApi.
For pre-installed live wallpaper apps, change to @SystemApi so:
1. apps can be build with gradle build tools.
(e.g.: PixelLiveWallpaper for app bundle feature).
2. apps can calculate and pass color hint information to interested system components.
(Such as passing dark text support to SystemUi)
Fixes: 111395593
Test: make system sdk and check if the wallpaper apps can compile with android_system.jar.
Test: check whether the wallpaper apps can pass correct color hint after build (dark text).
Change-Id: I2ecf6ff77ff7a823949c6e3253a077e6eba9683a
Also fixed AssistStructure.ViewNodeBuilder.setVisibility() so it doesn't mess
up with the flags when it receives an invalid value.
Test: atest FrameworksCoreTests:android.view.contentcapture.ViewNodeTest
Test: atest CtsContentCaptureServiceTestCases
Fixes: 121135096
Change-Id: I2280c6922ca5a02aa4ed16ba3e8b39b9cb2f4b55
Currently, Activity#onUserLeaveHint() may not have clear enough
information descripting when it would be called. Updating
document to also check Intent#FLAG_ACTIVITY_NO_USER_ACTION
for reference.
Bug: 121282783
Test: m -j PRODUCT-sdk_x86-sdk
Change-Id: I3894efbe286575140afbbba2ed059fd0f129ef3b
- Fix bug in call identification parcelable; was reversing the app name
and package name.
- Add @hide RoleManager consts for the Telecom roles; this will be
replaced by values in the library for public consumption as a later
date.
- Add new call direction attribute to the Call.Details class; this is
needed so that a CallScreeningService can know if a call is incoming
or outgoing. This way it knows whether it needs to perform call blocking
or just caller ID.
- Update CallScreeningService API docs to explain how to request the
call screening role.
- Update InCallService API docs to explain the 3 roles related to this
service and how you declare an appropriate IncallService to fill each of
them.
Bug: 63966743
Test: Manual, CTS
Change-Id: Ic4547b8ead791690305f7be58e43272c4155b7fb
