Suggested language list alignment should be as per the default locale.
Test: 1. RTL language
2. Settings>System>Languages & input>Languages>Add a language>English
3. Check the alignment
Bug: 70360392
Change-Id: I934b1061fb897ac69270a493562defba4a5a1a35
Signed-off-by: susanta.patra <susanta.patra@lge.com>
Together with checking isObservableEventType this will result in a11y events
not being generated for packages that are excluded form a11y-service(s)
package whitelist
Test: cts-tradefed run singleCommand cts -d --module CtsAccessibilityServiceTestCases
Change-Id: Id65607aaccc7af7d870d009d609917ff3c6d0712
When an app is on the top of the activity stack but the screen
is not on, this doesn't really count as a top app in the normal
sense. In particular, we'd really like to apply the normal
restrictions we have on background and cached apps: no network
access, no ability to use wake locks, etc. (In other words, in
this state the app's activity is stopped, so from its perspective
it is no different than the user leaving it to go to another app.)
To do this, we change the order of the TOP_SLEEPING proc state
out from the range of foreground states down to between the
cached and background states.
Test: ActivityManagerProcessStateTest
Bug: 70808931
Change-Id: I994caba8c27553a452de75efa358be0e683d046f
1) Updates to ILockSettings.aidl
Since we can't pass arbitrary exception using IPC, Serrvice
converts them to ServiceSpecificException with an error code.
2) Added RecoverableKeyStoreManager class which is used as interface
between RecoverableKeyStoreLoader implementation and
LockSettingsService.
Test: none
Bug: 66499222
Change-Id: I03b695bc0ced1a91ea7ca5de179e121053dfe416
This allows us to generally treat heavy-weight processes in
the background as cached processes, applying all of the limitations
we want for such things -- disable wake locks, etc.
Test: run-am-test ActivityManagerProcessStateTest
Bug: 63937884
Change-Id: I7c140c8f48188f6aa9c09731e83e3db4e4405e77
This CL is a generalized version of my previous CL [1], which addresed
Bug 31056744 where InputMethodManager (IMM) fails to recover from
failure mode when IMMS#startInputOrWindowGainedFocus() failes because
the app's window is no longer eligible to be the IME target.
This CL finally addressed one TODO in that CL. InputBindResult now has
the error code, which allows us to force restart input upon the next
window-focus-in event. This should make IMM much more robust for
that kind of failure modes. For instance, Bug 70629102 is fixed as
demonstrated in a newly added CTS test case [2]. Hopefully this may
also fix Bug 31056744, which we still do not know how to reproduce.
[1]: I60adb38013b063918b074c7b947649eada77b2c8
8e9214b4bd
[2]: I4ea24c87cbbd05e4e68ad7dfafb774c8520188e2
Bug: 31056744
Fixes: 70629102
Test: Added a test case for Bug 70629102
atest CtsInputMethodTestCases
Test: Manually made sure that Bug 28281870 is still fixed:
1. Open app that has EditText.
2. Start Input.
3. Long press the task switch button to start multi-window mode.
4. Tap the EditText that is used in step 2.
5. Make sure that the IME still works as expected
Test: atest CtsViewTestCates
Change-Id: I7572d4b9d678f3669ca54d55718877b145015777
When DISALLOW_UNIFIED_PASSWORD is enforced by managed profile
owner, the user is disallowed to user single lock for both primary
user and the profile.
DMP.isUsingUnifiedPassword() can be called by DPC to check if
this restriction is obeyed.
Test: make cts-verifier
Test: cts-tradefed run cts -m CtsDevicePolicyManagerTestCases -t
com.android.cts.devicepolicy.ManagedProfileTest#testIsUsingUnifiedPassword
Test: cts-tradefed run cts -m CtsAdminTestCases -t
android.admin.cts.DevicePolicyManagerTest#testIsUsingUnifiedPassword_failIfNotProfileOwner
Bug: 63909482
Change-Id: Ib758e32d4bf4012d805185bce874f481e17576ba
If the device has no battery, or has a removeable battery that is
currently removed, do not collect battery statistics.
Bug: 34507420
Test: manual: dumpsys batterystats
Change-Id: Id8edb494f353a40c648f798690f611f89f464d34
Previously, if a file was renamed, it would not be rescanned by the
media scanner. This caused for sound names to reported incorrectly after
renaming a file.
Bug: 70583116
Test: manual - rename a file in Alarms folder using downloads and ensure
new name is reflected
Change-Id: I42b9b4a4cda638d94b713575eb9e51feb2004cfa
Historically SOFT_INPUT_STATE_VISIBLE/SOFT_INPUT_STATE_ALWAYS_VISIBLE
have not required focused editor View [1] to work. This is easy to
use, but also easy to tell IMEs to connect to InputConnection, which
is often recognized as a bug by users because often nothing happens
when the user taps the software keyboard.
This would become more obvious when we start allowing nothing to have
focus (Bug 68841055) in Android P.
Although how we should deal with "dummy InputConnection" is still an
open question, ignoring these SoftInput flags for apps that target P+
when there is no focused editor view is probably better than the
current behavior, where non-functional software keyboard is likely to
be shown. The user is still able to show the IME by explicitly tap
the edit field.
As an implementation note, this CL trusts the targetSdkVersion
reported from the target application process, which is in general
unsafe. That said, for this particular purpose it is acceptable.
[1]: focused View that returns true from View#onCheckIsTextEditor().
Bug: 69256929
Test: atest CtsInputMethodTestCases
Test: atest FrameworksCoreTests:com.android.internal.inputmethod.InputMethodUtilsTest
Change-Id: I56682c7dee71d461687b9e80ab746d382fd55e0c
This is a preparation CL to add a new command to 'adb shell ime'.
Currently 'ime' command is written in Java language that relies directly
on the internal Binder IPC interface IInputMethodManager.
This is not ideal because:
1. We have to keep maintaining IInputMethodManager methods used
only by the 'ime' command.
2. Adding new options to the 'ime' command is tedious when it
requires new methods in IInputMethodManager.
With this CL, all features of 'ime' command are re-implemented inside
InputMethodManagerService (IMMS) on top of Binder's "shell command"
feature [1]. Like 'am' command was gone recently [2], now 'ime' command
is also a simple shell wrapper to forward options to 'cmd input_method',
which allows us to 1) reduce the code duplication and 2) give non-zero
status code when the command fails with Java exception.
[1]: I76518ea6719d1d08a8ad8722a059c7f5fd86813a
9461b6f91f
[2]: Ia8187196af597046fd2e7092dbf19ce1dc1ea457
1704e3cf0c
Bug: 70475949
Test: adb shell ime
Test: adb shell ime help
Test: adb shell ime dump
Test: adb shell ime list -a
Test: adb shell cmd input_method
Test: adb shell cmd input_method help
Test: adb shell cmd input_method dump
Test: adb shell cmd input_method list -a
Change-Id: I9a2dbbf1d4494addbe22c82e2c416eedc4d585f2
Also remove 'build.master@android.com' which is deprecated, not
declared by anybody else, and makes the linter unhappy.
Bug: 70394432
Test: built
Change-Id: I9c0ba41386129379f82259fcc5e745562b014fae
First CL that introduces SurfaceAnimator/LockFreeAnimator
We start our synchronized app transition journey by showing that
the concept works by using WindowState animations as proof of
concept.
The main class in this CL are SurfaceAnimator and
SurfaceAnimatorRunner. When we start an animation on a Window, we
create a new bufferless surface, called "The Leash", in the
hierarchy and attach the surface of WindowState onto it, while
attaching the leash onto the old surface parent which is still
responsible for z-layering.
Then, we pass off the Leash into SurfaceAnimationRunner, which then
changes the surface properties of Leash in every animation frame,
without holding the WM lock. While it's doing that we can still
update the z-layering of the window, or even relayout the window
of needed - the important surfaces for this are still under WM's
control.
In case the animation is finished the window surface gets
reparented to its original parent, and the leash is abandoned.
Note that the reparenting is done in the same transaction as
processing the animation finish, such that we don't end up with
a flicker in case of a disappearing animation, where the window
surface gets destroyed.
In case the animation needs to be cancelled, WM can revoke control
of the leash by reparenting the window surface. Even if the
cancellation signal is heavily delayed, WM immediately regains
control over the surface by reparenting it within a transaction.
We also introduce the concept of animating a WindowContainer. We
clean up isAnimating:
- isLocalAnimating: is the container itself animating
- isAnimating: is the container or one of its parents animating
- isSelfOrChildAnimating: is local animating or any child
animating.
SurfaceAnimationRunner also needs it's own thread so it's not getting
bogged down by any WM lock contention by processing regular
animation frames. We call that thread android.anim.lf (lockfree).
Now, imagine that SurfaceAnimationAnimator would sit behind an IPC in
another process and instead of animating WindowState, we'd animate
AppWindowToken. Then, synchronized app transitions would be done.
Test: go/wm-smoke
Test: SurfaceAnimatorTest
Test: SurfaceAnimationRunnerTest
Test: WindowContainerTests
Bug: 64674361
Change-Id: I10d41f7a289ab2158da3f2f1c3ddd78edd1efc86
Exempt-From-Owner-Approval: Tiny change unrelated to display management.
The log can be used to test if LAST KMSG or other items are copied
to dropbox successfully, especially in user builds without root
privilege.
BUG: 69685635
Test: manually verified the desired log from bugreport on user
and userdebug builds.
Change-Id: I6570d95538d678c98d261690ca3c20416d7a31c6
Merged-In: Ie6033bf04c7f79fc596761ab751aa5fcea2c1130
(cherry-picked from commit bafcd7b595)
The log can be used to test if LAST KMSG or other items are copied
to dropbox successfully, especially in user builds without root
privilege.
BUG: 69685635
Test: manually verified the desired log from bugreport on user
and userdebug builds.
Change-Id: Ie6033bf04c7f79fc596761ab751aa5fcea2c1130
Buttons should be aligned opposite to English in RTL languages.
Test: 1. RTL language
2. Create an alert dialog having positive, negative and neutral button.
3. Check the button bar alignment
Bug: 70363698
Change-Id: I783dfdcf9cb3f85402a4ff3fa4c2d1d1caf5c3da
Signed-off-by: susanta.patra <susanta.patra@lge.com>
This change adds support for VR-only IMEs in InputMethod framework.
In order to set this VR IME, setVrInputMethod(ComponentName) should be
called by VrManager.
When VrManager calls setVrInputMethod(), IMMS changes updates
the selected input method in a transient way i.e. it doesn't
update the Settings or input history. Once VR mode finishes,
it restores last input from settings.
Bug: 63037786
Test: Manually using the sample app in bug.
Change-Id: I1db7981b5198e7e203d4578cae7e5b6d20037d0d
Adds the logic to dispatch a DisplayCutout from DisplayFrames
through WindowState to the View hierarchy. Does however not yet
change how windows are laid out in response to a DisplayCutout.
The display cutout is currently never present, the following CL
will add logic to emulate a display cutout on devices that do
not have a physical one.
Bug: 65689439
Test: runtest -x frameworks/base/services/tests/servicestests/src/com/android/server/wm/WindowFrameTests.java
Change-Id: Ie4cd4b575755b66a7ffead31e28640983ef4894e
In addition, this also provides multiple strategies for mapping from
ambient room brightness in lux to display brightness. The default one is
the classic strategy, where we map directly from lux to backlight
brightness in an arbitrary unit. The newer and preferred strategy is to
use the physical brightness of the display, but requires that the
brightness properties of the display are appropriately configured.
Bug: 69406783
Test: atest com.android.server.display.BrightnessMappingStrategyTest &&
atest android.hardware.display.BrightnessConfigurationTest &&
atest android.hardware.display.PersistentDataStoreTeset
Change-Id: I60227bdb6c299d0fa92686cbf3e5994b336a3a79
