... Also
- change the constructor of the Builder of this class
- Do not crash if the subsitutions for the regexes are invalid
Change-Id: I965d5830f4932eb40ec22d7fa308815955920a99
Bug: 62534917
Test: cts-tradefed run cts-dev -m CtsAutoFillServiceTestCases
SurfaceControl.
In a recent CL we introduced a call to Surface#createFrom, in order to
recreate the Surface object from the underlying SurfaceControl, as a
workaround to emulate when it was parcelled over binder in the past.
However this is causing BufferQueue abandoned errors when stopping and
resuming some applications. To understand them, we need to revisit the
SurfaceView destruction process when handling onStop.
First mWindowStopped will be set to true (SurfaceView#windowStopped),
and we should then enter updateSurface. Our requested visibility will
now be false and so we emit the Surface destroyed callbacks. Notice in
the finally block in mUpdateSurface, we will release mSurface, but we
will NOT null mSurfaceControl. Inline documentation explains why.
In the case that the activity is not actually being destroyed, it's
possible that we may not get a dispatchDetachedFromWindow. This means
that we will not null mSurfaceControl. Now if the activity is
un-stopped and we re-enter updateSurface we encounter a problem
state. "creating" will be set to false since mSurfaceControl != null,
however mSurfaceControl will not point to a valid surface.
Prior to the introduction of the #createFrom call, this unwanted state
didn't cause any problems. Because mSurface was released back in the
finally block as we were stopping we now fall out of the
mSurface.isValid() block in updateSurface. As we reach the finally
block again, we would now set mSurfaceControl=null since the app was
no longer stopped. Later when we reach updateSurface again (which
tends to happen quite often) it will now be null and we will correctly
set creating=true, create a valid SurfaceControl, and move along
happily. However following, the introduction of this
Surface#createFrom call we will now reinitialize the Surface from an
invalid underlying SurfaceControl. This means we will enter the
mSurface.isValid block, but will proceed to emit an invalid Surface to
the client in the callbacks.
We avoid this state by making creating=true even if
SurfaceControl=non-null when the calculated visibility changes from
invisible to visible.
Bug: 63251745
Test: Manual of app from bug and apps from previous related bugs. go/wm-smoke. Additional manual testing of many SV apps.
Change-Id: Icc32a34cac239d65267da705cc23feb23e1ceb67
Fixes: 37245619
Test: go/wm-smoke; Go to home, turn off phone, observe that during the transition to AOD the navigation bar hide animation does not play.
Change-Id: I9a2fce4295900648a680e8e7e8fee0fbb447dd3d
When a window with this flag is visible, then any other window added
by an application process that requires OP_SYSTEM_ALERT_WINDOW
permission or that are of TYPE_TOAST will be hidden.
Bug: 62196835
Test: go/wm-smoke
Test: Added the new flag to the RecentsActivity onCreate, launched FB
chat heads and observed the head head become invisible when Recents is
visible and the chat head become visible when Recents is no longer
visible.
Change-Id: I1a3e3c5b1696a5f5b95eac187acb5a03863b4a0b
The constant will become visible once
the corresponding feature is supported.
Bug: 62433331
Test: make
Change-Id: I310338033dd861e9fd0cc1492a8e34fb53ce0415
Previously, the server side would omit reporting new configurations
during resize and relayout if the current configuration matched the
last reported. However, if the last reported came through a resize,
the client side handling would be enqueued as a Handler message. This
leads to the possibility of the client getting a new window frame but
not a new configuration where this is synchronously handled, such as
ViewRootImpl::performTraversals.
To address this issue, we now always send the current configuration
from the server to the client. The client then identifies changes
against its own record of last reported configuration and updates as
appropriate.
This changelist also adds a call to force window relayout during
updateConfiguration, as it's possible this is called after
performTraversals is called or resize is handled, leading to a stale
window frame.
Bug: 24671393
Test: go/wm-smoke
Test: Open Camera while rotating phone to landscape. Added
temporary logs to detect inconsistencies between measurements
and reported rotation on draw.
Change-Id: I0d5143dfe80400f6a43ce710750f9fc9d4b93f74
I submitted this change by accident after confusing it with one of mine. Sorry.
Bug: 62196835
This reverts commit 6f2a1a18fc.
Change-Id: Ib6d89690d1d761d38da3131131ff807a3fac0d2b
Certain activities are dependent on the rotation of the device to
determine layout. In these cases, orientation does not provide enough
details.
This CL adds the field (hidden) to the configuration.
Change-Id: Idb3ba10cb4de8838737c25e92264e6cee224e264
Fixes: 32839232
Test: go/wm-smoke
Previously, TextServicesManager was exposing APIs to system services to
modify spell checker settings. However, Settings application is the only
client of these APIs and there is no need to expose it to all the other
services. Settings app already has the WRITE_SECURE_SETTINGS permission
and can directly update the spell checker settings. Hence, we can remove
these APIs from TSM.
Fixes: 62950392
Test: Manually as follows.
1. Build and flash an OS image.
2. Complete the setup wizard (if any).
3. Make sure AOSP Keyboard (com.android.inputmethod.latin) is installed
4. Install SampleSpellCheckerService
4.1 tapas SampleSpellCheckerService
4.2. make -j
4.3. adb install -r out/target/product/generic/system/app/SampleSpellCheckerService/SampleSpellCheckerService.apk
5. Set the current spell checker service to be AOSP SCS by
adb shell settings put secure selected_spell_checker com.android.inputmethod.latin/.spellcheck.AndroidSpellCheckerService
6. Run a test program that has TextView and tap on one of the
TextViews and type some text.
7. Observe that there is a connection to AOSP SCS by
adb shell dumpsys textservices
8. Set the current spell checker service to be
SampleSpellCheckerService SCS by
adb shell settings put secure selected_spell_checker com.example.android.samplespellcheckerservice/.SampleSpellCheckerService
9. Observe that there is a connection to SampleSpellCheckerService
SCS by
adb shell dumpsys textservices
Change-Id: I4513ca661788f00785f684c21d7244c233b6e33e
Added two new flags to the Activity to turn the screen on and
show on the lock screen. These can be used instead of the Window flags
LayouParams.FLAG_TURN_SCREEN_ON and LayoutParams.FLAG_SHOW_WHEN_LOCKED
to prevent the double onStart/onResume lifecycle events.
The flags can be set as an attr for the Activity in the AndroidManifest
using android:showWhenLocked="true" and android:turnScreenOn="true".
They can also be set through methods in the Activity class using
setShowWhenLocked(true) and setTurnScreen(true).
Fixes: 36850100
Test: Created sample application, tests/ShowWhenLockedApp, that set the
flags in the manifest and code. Tested multiple scenarios to
launch the Activity with the flags set and unset.
Test: cts-tradefed run commandAndExit cts-dev --module CtsServicesHostTestCases -t android.server.cts.KeyguardTransitionTests
Test: cts-tradefed run commandAndExit cts-dev --module CtsServicesHostTestCases -t android.server.cts.ActivityManagerActivityVisibilityTests
Test: cts-tradefed run commandAndExit cts-dev --module CtsServicesHostTestCases -t android.server.cts.KeyguardTests
Change-Id: I44f0e313df4531d49c7ac56108b6bf80e41fefc1
When a window with this flag is visible, then any other window added
by an application process that requires OP_SYSTEM_ALERT_WINDOW
permission or that are of TYPE_TOAST will be hidden.
Bug: 62196835
Test: TODO
Change-Id: I07605b52af893945250b0212f406e0e92bfd92bd
This is a followup to ag/2370980/ to expose the API more
externally as a WindowManager API. This allows application
access without needing to reflect on IWindowManager.Stub.
We require this to get the current IME touch region to
display it properly in VR contexts.
Test: Manual
Bug: 62194867
Change-Id: Ibbf336e1e473b65d4c76a1492da187d50cfda424
The attributes for View, paddingHorizontal and paddingVertical,
were added in the O release and are documented in R.attr. But they
should also be referenced in View itself, alongside the other
padding parameters.
Similarly, the new layout_MarginHorizontal and
layout_marginVertical should be referenced in
ViewGroup.MarginLayoutParams.
Bug: 63128350 Add docs about new padding/margin params
Test: built docs, checked the result
Change-Id: I3021df5ea83c469811b4a6ec6ecd3ab2966ec384
The description for `AutofillManager.isAutofillSupported` doesn't make
clear that either the device or the user can make autofill unsupported.
Bug: 62604325
Test: Ran 'make ds-docs -j16' and staged content to
go/dac-stage/reference/android/view/autofill/AutofillManager.html#isAutofillSupported()
Change-Id: I298b9f535e23dc3cb54fabed36642523753c13a5
Apps with a normal UID are typically isolated enough to not require
socket tagging; we're mostly interested in tracking down internal
UIDs that have lots of code sharing the same UID.
Also fix up everyone doing manual string checks of Build.TYPE, since
we now have first-class fields for those.
Bug: 38126076
Test: builds, boots
Change-Id: I3a40348196bd8459289f2b9355d9783a07f1e7dd
