It turns out that AppRestrictionsHelper#addSystemImes() has always
queried for the owner user's system IMEs despite the fact that it's
trying to query system IMEs for a restricted profile user. This
behavior has not changed since its beginning [1].
Most likely people would not have noticed this though, because:
* Settings app does not show a menu item to create a restricted user
on phone devices.
* Even if it's available, most people do not use restricted users.
* Even if someone created a restrected user, most likely the owner
user and the restrected user share the same set of system IMEs,
which are defined as "pre-installed" IMEs.
Anyway, AppRestrictionsHelper#addSystemImes() will start using a newly
introduced @hide API IMM#getEnabledInputMethodListAsUser() so that it
can query for the right user's system IMEs, instead of querying owner
user's ones.
[1]: Ifced841ad3bfbde33d2403356216dd1749b7fa9a
a7a93784d1f9798d37cb618def1a558f8d626f0f
Bug: 122164939
Test: atest SettingsLibTests:AppRestrictionsHelperTest
Test: manually done as follows.
1. Build aosp_taimen-userdebug and flash it.
2. adb shell pm create-user --restricted test_profile
3. adb shell am start -a android.settings.USER_SETTINGS
4. Click the gear icon next to the "test_profile" user.
5. By adding a log, make sure that IMMS#getInputMethodList()
gets called with userId = 10.
Change-Id: I5b50b5fe143c74c87b331bda3e5bcc4d6248436e
Developers should use setTransitionVisibility instead of using
reflection to change the visibility in mViewFlags directly.
Bug: b/123768691
Test: CTS test in topic
Change-Id: I04d76100c53238b92cdc1575bc20af2a6b4410fe
This CL fixes a regression introduced by my previous CL [1], which
enabled InputMethodManager#getEnabledInputMethodList() to return the
result based on the caller's user ID, not based on the current IME
user, even when it gets called from background users.
Since Keyguard always runs as user 0 currently, it is now Keyguard's
responsibility for querying enabled IMEs with an explicit user ID. To
do so this CL adds a @hide API IMM#getEnabledInputMethodListAsUser()
and lets KeyguardPasswordView use it.
[1]: I192a0f5a1375170d17a4c08af94f23966dbaea8b
7f8ee4b9dd
Bug: 122164939
Fix: 123904896
Test: Manually verified as follows.
1. Build aosp_taimen-userdebug and flash it.
2. make -j SoftKeyboard
3. adb install -r $OUT/system/app/SoftKeyboard/SoftKeyboard.apk
4. adb shell ime enable com.example.android.softkeyboard/.SoftKeyboard
5. adb shell pm create-user test_user
6. adb shell am switch-user 10
7. adb shell locksettings set-password aaaa
8. adb shell wm dismiss-keyguard
9. Make sure that the IME switcher icon is not shown at the right
end of the password field.
Change-Id: I6e7d7353c2b5b1da5d460ae005fb2585f85fb1c4
This is a follow up CL to my previous CL [1], which enabled following
IME query APIs to return the result based on the caller's user ID, not
based on the current IME user, even when they get called from
background users.
* InputMethodManager#getInputMethodList()
* InputMethodManager#getEnabledInputMethodList()
* InputMethodManager#getEnabledInputMethodSubtypeList()
This CL just clarifies it in the API documents.
This is purely a document fix. There should be no behavior change.
[1]: I192a0f5a1375170d17a4c08af94f23966dbaea8b
7f8ee4b9dd
Bug: 13002424
Bug: 122164939
Test: make -j checkbuild
Change-Id: I55f51e211a8a47c01469e2d93b04c5c864f0b9ea
Users should rely on the getter / setter. The setter additionally
guarantees internal state correctness.
Bug: 123768937
Test: n/a
Change-Id: Ia2dcbe9db3fdeab8aeac9b80dcfaaa0932724dc2
Most calls are bufffered anyways, so by not using a handler we save time spent
on getting a pooled lambda and posting to the the handler.
The only "expensive" operation is flushing, but it makes a oneway binder call
so it might be fine (and if necessary, we can optimize it later).
Bug: 123307965
Test: atest CtsContentCaptureServiceTestCases
Change-Id: I7182c8e193f58fa000396fdb3003e771214bf79b
The overall workflow of Content Capture is:
- send initial structure
- send deltas afterwards
Initially, the initial structure was being reported one view at time, which was causing janking.
This CL changes it so while that while the initial structure is being laid out, the content captures
are held. Then after it's finished, it traverses the structure and sends the initial events.
This change also allowed use to optimize the performance by caching the following state:
- View.isImportantForContentCapture()
- View.getContentCaptureSession()
- Context.getContentCaptureManager()
Besides the performance improvements, this approach also has the following advantanges:
- It sends the VIEW_APPEARED events for the parent views before the events for the children.
- It send events to notify when the view structure layout is ready.
Bug: 123307965
Test: atest CtsContentCaptureServiceTestCases
Test: m update-api
Change-Id: I6db7cc11c6edf65cbffe42187fda82c84c3665ff
A few getters for view properties have been added where they were
missing. CTS tests for the new APIs are pending in b/123894719.
Test: m framework
Bug: 120492712
Change-Id: I743ce693d384eaf749ced3db7f81bda7d19ed275
This is a value provided by ViewConfiguration that is standardized
across the device. There are two problems in changing this:
1. inconsistent behavior with the rest of the uses
2. modifying this would open the door to modifying all slops,
which is infeasible and has no good API story
Bug: 123769434
Test: No API or behavior changes
Change-Id: I30bc9d065be8633752a67bd0faa9eafe1678e843
With this change, InsetsController.show/hide now links to IME. This also
takes care of animating IME along with other types.
Insets API are reactive i.e. they remain in sync with state of IME.
Test: atest InsetsControllerTest
Test: atest ImeInsetsConsumerTest
Bug: 118118435
Change-Id: Ib3997487bd19351d1d23bc70173fc9bdfd23a704
Sends the IME control to the client by calling
InsetsStateController.onImeTargetChanged.
Furthermore, since the frame we use to calculate the insets isn't
necessarily the surface frame, we also need to pass down the
surface position such that the client can calculate the final
leash position correctly.
Test: Open IME
Bug: 111084606
Change-Id: Ifed8351b12d47f698efde504205bd7b77032d36b
Added runtime namespace and corresponding device config property. If
the property is enabled, it overrides the system property.
Bug: 123524494
Bug: 111895153
Test: manual
Change-Id: I97f094e3a8471b72255b27fd0f10160040d49175
Such that elements are more in sync, and this is also how it was
handled previously.
Furthermore we ensure that surface visibility is correct after the
animation for both show and hide.
Test: Show/hide IM
Bug: 111084606
Change-Id: I47b3d3b430fa38f80203276b9984df1f71008f6e
Previously setColorMode must be called before view is set, and has no effect
after that. The state of WCG on Android when this patch was written, was that
most hardware out there can not handle mixed color spaces composition well
which results in GPU composition. And this situation will remain true for a
long time.
Despite photography applications want to have WCG, it's a power cost especially
during video playback. In order to mitigate this fact and the desire to move
the ecosystem forward in WCG, we make setColorMode togglable such that in the
next app vsync, when color mode is changed we issue a surface update which
results in the old EGLSurface or VkSurface being destroyed and new EGLSurface
or VkSurface being created with the target color space being set. As a result,
applications can now togglable WCG on/off.
BUG: 120288123
Test: Build, flash and boot. Verify with SurfaceFlinger dumpsys on demo app.
Change-Id: I09bf8c380a01f4dde364873d37b248cedc6ccfd3
We have defined the same constant twice. Let's move it to
ViewConfiguration to avoid redundancy.
Test: build only
Bug: 123368517
Change-Id: I2ac765a85ccd71584429edc693d3ef33b2515c9d
Each ContentCaptureManager has a MainContentCaptureSession associated with, and the main session
has a mDisabled state that's set to true when it failed to start (for example, because there's no
service associated with the user). Both objects used to share a common AtomicBoolean for the
disabled state, but a recent refactoring split then in a way that the manager's mDisabled was never
updated.
Test: atest ChildlessActivityTest#testGetContentCapture_enabledWhenNoService
Test: atest CtsContentCaptureServiceTestCases # sanityCheck
Bug: 123579223
Bug: 123307965
Bug: 123658889
Change-Id: Ib1f08f23721f208b28d0f339f39b21262b55e30d
Currently, Chrome is using this flag via reflection.
Let's allow developers to use this flag.
Fixes: 120487602
Test: presubmit only
Change-Id: Id28bd1f2cb862bb49f27758a4948f197bba124e2
This reverts commit 139c77763b.
Reason: Device gets put into GL comp pretty much all the time,
trashing performance and battery.
Bug: 123686354
Bug: 122561221
Change-Id: Icf658f331c407d03e844557cc2531c034aa38083
Exempt-From-Owner-Approval: Simple revert
Also remove the restriction of extractNativeLibs.
Test: build, (new) CTS in progress
Bug: 112037137
Change-Id: If0ad13b0d63b288c2da3a82b911d8dad0db8c07a
This logs a "view" event for the translate action *once* for each
selection session that involves a foreign language. It logs a "click"
action when the translate action is clicked.
The logged action index will give an indication of whether the translate
action was the primary action (index 0) and thus immediately visible to the
user or whether it was one of the secondary actions (index > 0) and
possibly in the selection toolbar's overflow.
Bug: 123414932
Bug: 120837847
Test: atest core/tests/coretests/src/android/view/textclassifier
Test: atest cts/tests/tests/view/src/android/view/textclassifier
Test: atest android.widget.TextViewTest
Test: atest android.widget.cts.TextViewTest
Test: (MANUAL):
1. Ensure device has an app that supports Intent.ACTION_TRANSLATE
2. Run the following command on the shell: adb logcat -c "TCEventTronLogger"
3. Select some foreign lanugage text in a TextView
4. Click on "Translate" item on the toolbar
5. Observe that the device logs a "view" and a "click" event
6. Repeat 3
7. Click on a different menu item, e.g. "Copy"
8. Observe that the device logs only a "view" event
Change-Id: I36f32459c577cf8f8bcf1e65960c4e6d7ffa5e01
The bitmap.createHardwareBitmap doesn't take a ColorSpace as input, as a result
the returned bitmap is always in SRGB color space. Given that we want to remove
the assumption of SRGB color space, we replace the usage of
createHardwareBitmap with wrapHardwareBuffer which takes an extra argument
ColorSpace. As a result, we will be able to also fix SurfaceControl and various
other places that use screenshot in follow up patches.
BUG: 120904891
Test: CtsUiRenderingTestCases
Change-Id: I57fc0c85d68df43b0e69f9a1ebac00d2ba39554d
