As discussed in Bug 33038203 on certain platforms there is a demand
that the power button can change the behavior depending on whether an
IME window is shown on the screen or not. The behavior requested here
can be summarized into two parts:
* Hide the IME window if it is shown [1]
* Go to the home screen if no IME window is shown
This CL implements the above request by introducing a new config mode
for config_shortPressOnPowerBehavior. Note the definition of when an
IME is shown is often tricky than people would expect. The way this
CL is implemented is to propagate IME window state from
InputMethodManagerService (IMMS) to PhoneWindowManager via
WindowManagerService regarding when the back button on the NavBar for
phones/tablets should be shown as an IME dismiss key [2].
[1]: Even with this CL the IME still is allowed to ignore the request
to hide the software keyboard. Currently there is no official
protocol to forcefully hide the software keyboard. How to deal
with such a situation is a long standing TODO task.
[2]: Internally this is controlled by the following IMMS fields:
- InputMethodManagerService#mImeWindowVis
- InputMethodManagerService#mBackDisposition
Note that those fields rely on self-report from the IME. To be
precise, the base implementation of InputMethodService is
responsible for report back its internal state to IMMS when
necessary. The important point is that, although this could
allow a malicious IME to confuse the system UI to some extent,
supporting malicious IMEs is not clearly a goal of Android.
Anyway, the definition of when an IME is shown is a kind of
hot topic in several system services recently. Hopefully we
can come up with better definition and reliable mechanism in
a future release.
Fixes: 33824860
Test: Manually verified as follows
1. Change config_shortPressOnPowerBehavior to "5"
2. Rebuilt the OS image and flash it to the device
3. Make sure that the power button works like a home button
if software keyboard is not shown.
4. Open dialer and focus in to the text field shown on top
5. Make sure that the AOSP keyboard is shown.
6. Run 'adb shell dumpsys input_method' to observe the
following line:
mImeWindowVis=Active|Visible
7. Tap the power button to make sure that the AOSP keyboard
gets dismissed.
8. Tap the power button again to make sure that it works
as if a home button.
Test: Manually tested as follows
1. Open dialer and focus in to the text field to show an IME
2. Run 'adb shell dumpsys window policy' to make sure
mDismissImeOnBackKeyPressed=true
3. Tap the back button to dismiss the IME
4. Run 'adb shell dumpsys window policy' to make sure
mDismissImeOnBackKeyPressed=false
Change-Id: I20721547c73360a70b5fc5cbe06824d577d1768a
The job queue now handles URI permissions associated with
the Intent of each job. Just (kind-of) like Service!
Also do the second pass of locking in job scheduler, getting
rid of all the async dispatching on a handler, and just executing
calls right in line with simple locking. This probably fixes
a few other race issues, and allows us to make sure that we
always finish a job correctly when dequeuing the last work (we
will always atomically dequeue and finish, so no new work can
slip in between).
And fix a little debug output in IntentFilter.
Test: ran CtsJobSchedulerTestCases, added new test for URI perms.
Change-Id: I52f700ef0cd5be3ff70050f9c0f5fe3e8a5ccac1
- As a part of transitioning into PiP, we remove the content insets, and
as a result, we also need to adjust the source hint rect for the change
in insets as well.
Bug: 37418994
Test: Enter PiP from YT, ensure no jump at the end
Change-Id: I74219b05c91d3c8b8466dd8fff4d6dd692f08725
- JobServiceEngine now takes a concrete Service instead of
generic Context in its constructor, since it really must be
associated with a real Service.
- Expand documentation of how dequeueWork() operates.
- Fix some job scheduler implementation to hopefully actually
match the docs: transfer remaining executing work to the new
job, and actually correctly transfer state from old and new
jobs if we are rescheduling due to a true return from onStopJob().
Test: bit CtsJobSchedulerTestCases:*
Change-Id: Ia66797049883eefb566264f930070afb69d469b1
- Fixing up edge case when SysUI resizing conflicts with updating the
display rotation bounds. When an interaction causes both a display
rotation and a resize from SystemUI, we should defer the resize animation
until the rotation has been propagated to SystemUI, otherwise the bounds
used will be incorrect.
Bug: 36879891
Test: android.server.cts.ActivityManagerPinnedStackTests
Change-Id: Ife1b7ab0c2f1f11f33cbc9614778ff49a28c79f6
Based on API council feedback, switch to using real UUID objects
instead of Strings. Since UUID is a general-purpose utility class
that will be passed around quite a bit, add it to Parcel and Bundle.
Define well-known namespaced UUID values for "default" and "primary
physical" storage devices, which will let us annotate a bunch of
things with @NonNull.
Define new extras for MANAGE_STORAGE intent that apps can use to
signal where and how much space they'd like the user to free up.
Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.StorageHostTest
Bug: 37325923, 35812899, 35806020
Change-Id: I8421b126d680f69141a361c1e77223fe2bf4a325
An instance of ResourceKey may correspond to different instances
of Resources at different points in time. This can lead to old
instances of Display returned from cache even if resources have
changed.
We need to ensure 1:1 correspondence between Resources and
ResourceKey before using this kind of cache. Disabling it for now
to fix CTS.
Change-Id: Ib53550c4f2d969c06a570ab6051529269b04b38d
Fixes: 37328072
Fixes: 37305567
Bug: 33430498
Test: android.server.cts.ActivityManagerAppConfigurationTests
Test: android.app.cts.DisplayTest#testRotation
Adds a method isTheFinalCountDown that allows to correctly
determine whether it is the final countdown.
Test: None
Change-Id: I786ae3455479bac25ccf25efba1c3dce18185117
The purpose here is to provide support for selectively
enabling Runtime Resource Overlays (RROs) (specifically
those pertaining to a specific SKU, within a OEM's "single
build" covering multiple SKUs) at boot based on the value
of a pre-defined system property.
This mechanism is designed to be compatible with other,
recent changes to Runtime Resource Overlays - specifically:
- has no effect on 'isStatic'. Resource overlays must be
attributed as static in order to qualify for loading into
the system_server. The 'requiredSystemPropertyName/
requiredSystemPropertyValue' mechanism operates
independent of this and can be used on both static and
non static overlays. The effect of specifying a conditional
property on any overlay is that it will ONLY be enabled
in the event that the system reflects both the property
and the specified value (Note that in the ABSENCE of a
conditional property, overlays are assumed to be enabled).
- has no effect on OverlayManagerService (OMS) API. The
OMS provides the system with an interface through which
overlays can be enabled/disabled and even rearranged at
runtime. This provides the basis of support for various
user-level features (e.g. dynamic theme selection).
The 'requiredSystemPropertyName/requiredSystemPropertyValue'
mechanism operates independent of this -
with enablement being completely coupled to the available
system properties on the device and NOT subject to change
at runtime.
Note: as part of this change, original overlay tests have been
updated (fixed) and expanded to include tests to cover the
conditional property implementation.
Issue: http://b/35100249
Test: frameworks/base/core/tests/overlaytests/testrunner.py
Change-Id: I1990ce21a27a385db1e2f53294b69dd03988351e
(cherry picked from commit d5566c6c47)
Because listeners can see notifications on managed profiles.
Test: runtest systemui-notification and testing with a sample app
(reading and updating channels and getting change
callbacks on a managed profile)
Change-Id: I5d7af3c417e3a3d18f992cc9ad01fbd7959de398
Fixes: 36783632
An service can option to finish the session once all views that it
declared as important. Views that are important are all autofillable
views of any partition and the saveable fields of the last partition.
Test: CtsAutoFillServiceTestCases
Fixes: 35708237
Change-Id: I0ccade8ebb427e5d8928697ef0007c75d3f83df0
* changes:
[CM] Unhide the NetworkSpecifier as object API
Make the NetworkSpecifier a class instead of a string.
Add test coverage for NetworkSpecifiers.
Test: 1. Trigger the confitrmation dialog.
Ensure it looks exactly like the one from settings.
2. Call an API without associating the appa first
Ensure exception is thrown with a message mentioning the need to associate 1st
Change-Id: I94d4116e1988db869ed445ae3fd018c50590e3f4
Now it's possible to listen to changes on wallpaper colors by
registering a listener on WallpaperManager. It's also possible
to get the current wallpaper text color hints.
Bug: 36856508
Test: compilation
Change-Id: I5102cb7be9a4af60b85fc8913154a79dfe5c21a0
This value is necessary to easily look up the availability of a
recommendation (nee, scoring) provider; however it is only used by
bundled apps to monitor its availability, so hide the setting itself.
Test: make update-api; make; flashall
Bug: 34715823
Change-Id: Idf4591fd03d90207ef525f584793db65a1f6597c
When saving data filled by the user the platform provides to
an autofill provider the state of the UI allowing the provider
to interpret this state and store relevant information.
A limitation of the current design is that the fill provider
needs to interpret the screen content twice, once handling a
fill request and once handling a save request. To address this
we are introducing a id for each fill request allowing the
autofill provider to associate arbitrary state with each fill
request and store it in the client data bundle later passed
to save.
Another limitation of the current design is that if the screen
changes dynamically while the user interacts with the app the
UI state passed on save represents a static snapshot, therefore
it is not possible to the autofill provider to determine the
context in which the data in the UI was filled. We could
keep the views and have deltas for views being removed/added
/moved/changed but this is not enough as the fill provider
needs to know not only what changed but what changed for every
fill request and in one session there could be multiple fill
requests. To address this we provide a list of fill contexts
on save each of which has the id of the corresponding fill
request. This allows the fill provider to know the exact context
in which the data was popuplated and also use its custom client
state for this fill request if desired.
This change deprecates the old APIs and the new ones delegate
to the old ones. Once the clients migrate to the new APIs we
will remove the old ones.
Test: all autofill CTS tests pass
Change-Id: Idcebcc671aa3c078a305d8c358e225274fccc588
Override enableZsl based on app target SDK version so that for apps
targeting N and older, enableZsl is false for all template. For
apps targeting O and newer, enableZsl is false for all templates
except STILL_CAPTURE.
Test: CTS
Bug: 34983527
Change-Id: I2057e2351e81c269d322dffc199c58481ac3e78f
