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
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
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
The Usage Reporting Api allows apps to report usage within the app to
platform. Apps with the the OBSERVE_APP_USAGE permission may register
observers that use the reported in-app usage.
Test: manual (using the included Usage Reporter App)
Test: atest CtsUsageStatsTestCases:UsageReportingTest
Test: atest FrameworksServicesTests:AppTimeLimitControllerTests
Bug: 112486938
Change-Id: Iddd6f0993bbbf68a2032b34d473ef8d67da7747a
Removed isAppForeground from the ActivityManager aidl and added it to
ActivityManagerInternal. Updated all of its references as well.
Bug: 119327603
Test: atest cts.tests.app.src.android.app.cts.ActivityManagerTest#testIsAppForegroundRemoved
Test: atest WifiServiceImplTest
Test: atest WifiLockManagerTest
Change-Id: I5c0fbe41df3cd00e02f8c0e1005fc9cf5832df77
According to Android API council we shouldn't add a new semantic-action
flag to mark an action as contextual. Instead we should use a boolean
flag.
This CL adds that boolean flag.
Bug: 120842160
Test: build and run Notify app (in
vendor/google_experimental/users/cinek/), and ensure smart actions are
showing when the 'No Smart Actions' chooser is changed to
'Short Smart Actions'.
Change-Id: I5fc6dfa37ab28e3f29529cb6fda99c049783eb80
SurfaceView setVisibility handles removing the surface already. By
forwarding the visiblity call from AV to the SV, SV will destroy the
surface. It will callback into AV through SurfaceCallback.surfaceDestroyed.
In the callback, AV removes the surface for the display, causing the
virtual display to turn off. When the virtual display is turned off, the
activities on that display will get stopped.
Test: ActivityViewVisibilityActivity
Change-Id: Iea8b57d7871b8c87457f2ae19485a610d0d74c38
Tracking SurfaceFlinger changes. Now to construct a child surface
we need the SurfaceControl as opposed to just the surface, and so
we parcel the SurfaceControl across relayout.
Test: Manual
Bug: 62536731
Bug: 111373437
Bug: 111297488
Change-Id: I0a034767e92becec63071d7b1e3e71b95d505b77
As this has already evolved from just presenting data. In the future any
permission related calls to the permission controller will be added here.
As the calls are protected by different permissions the binding will not
require a permission anymore, but each individual call checks the
permission.
Bug: 120221960
Test: Looked at settings UI showing data from this interface
Change-Id: I6b4a5c3b7ee17b145e11e2c1b6e11a8a232bffed
By this CL, we could dispatch Callback to fragments on the specified
display. I also add some annotations for documenting.
TODO: 1. add tests for multi-display.
2. make registerStatusBar be an IStatusBar API to propagate the
information when a display is added or in the initial step.
3. Introduce AutoHideController
Test: atest SystemUiTests
Bug: 117478341
Change-Id: I864600f929c1d0c8aa39274f30c17b213b754d86
