When passed to native, this flag will tell a Layer that it should use
Composition.DISPLAY_DECORATION.
Bug: 193170859
Test: manual
Change-Id: I7f22dfd03d86786afee078a95f0af590be0bbdfd
Revert "Add tests to ensure hardware only for RuntimeShader API"
Revert submission 16475336-RuntimeShader_softwareOnly
Reason for revert: Breaking tests as system is dying
Error: Software rendering doesn't support RuntimeShader
Bug: b/211066630
Reverted Changes:
Id0ee4d1f0:Enforce that RuntimeShader is only hardware accele...
Ib4c2e54bd:Add tests to ensure hardware only for RuntimeShade...
Change-Id: Id7bbf2609a06c1cd69f6a457dab44f9478d95742
Changes:
- Listens to changes from the client coming through IActivityClientController#requestCompatCameraControl to ActivityRecord#updateCameraCompatState
- ActivityRecord#updateCameraCompatState sends updated state via TaskInfo to WM Shell
- ITaskOrganizerController#updateCameraCompatControlState to dispatch the user interactions with the control from WM Shell triggers callback to ActivityRecord#updateCameraCompatStateFromUser
- ActivityRecord#updateCameraCompatStateFromUser remembers the user's choice and asks client to apply treatment through ICompatCameraControlCallback
Feature is guarded with config_isCameraCompatControlForStretchedIssuesEnabled
Test: atest WMShellUnitTests:ShellTaskOrganizerTests, atest WmTests:ActivityRecordTests
Bug: 206602997
Change-Id: I083aa6718bd67456bedd9444e9b78740c041f870
Throw an illegal argument exception any time a Paint with
a RuntimeShader is attempted to be drawn into a software
canvas. Also mark that a Picture that uses a RuntimeShader is
properly marked as requiring hardware acceleration.
These tests check that the use of RuntimeShaders trigger
Bug: 189102731
Bug: 201546136
Test: atest CtsUiRenderingTestCases:RuntimeShaderTests
Change-Id: Id0ee4d1f05e2975031121298b45f925ee74f6818
Introduce new API for declaring Scribe support in IMEs.
CTS-Coverage-Bug: 210917621
Bug: 203086136
Change-Id: Ie012d865d58e6d41fe6ab6de479dd6ed86e6106c
The initial selection toolbar render service part architecture. The
implementation will be done in the follow up changes.
Bug: 190030331
Bug: 205822301
Test: manual. Call API and can bind service successfully.
Ignore-AOSP-First: new feature for T.
Change-Id: I3a5d3802c2afca432f137742cfd6a1e0045ed975
This CL also adds a test to ensure that a pointer source is used by
default when obtaining a MotionEvent, and that offsets are only applied
to pointer sources.
Bug: 207251886
Test: atest MotionEventTests
Change-Id: Id40accc6d1238c940f139a18b26fa277dd6e11f9
The initial selection toolbar related architecture. Render service
part and the implementation will be revised in the follow up changes.
Bug: 190030331
Bug: 205822301
Test: manual. Can boot to home and get manager successfully.
Ignore-AOSP-First: new file for T
Change-Id: Iab5d5f2e5e48e6258a63fb0c479194c958ea61e8
Migrate the following unsafe parcel APIs in framework-minus-apex:
* Parcel.readSerializable()
* Parcel.readArrayList()
* Parcel.readList()
* Parcel.readParcelable()
* Parcel.readParcelableList()
* Parcel.readSparseArray()
This CL was generated by applying lint fixes that infer the expected
type from the caller code and provide that as the type parameter
(ag/16365240).
A few observations:
* In some classes we couldn't migrate because the class also belonged to
another build module whose min SDK wasn't current (as is the case for
framework-minus-apex), hence I suppressed the lint check
(since I'll eventually submit the lint check to the tree).
* In some cases, I needed to do the cast in
https://stackoverflow.com/a/1080525/5765705 to make the compiler happy
since there isn't another way of providing a class of type
Class<MyClassWithGenerics<T>>.
* In the readSerializable() case, the new API also requires the class
loader, that was inferred to by InferredClass.class.getClassLoader().
* Note that automatic formatting and import rely on running hooked up
to the IDE, which wasn't the case here.
Bug: 195622897
Test: TH passes
Change-Id: I11a27b9bdab7959ee86e90aa1e1cbebd7aaf883c
This is a follow up CL to our previous CL [1], which had an off-by-one
bug when determining the return value of
EditableInputConnection#endBatchEdit().
According to the API document of InputConnection#endBatchEdit(), the
following test should pass.
EditText editText = new EditText(context);
EditorInfo editorInfo = new EditorInfo();
InputConnection editableInputConnection =
editText.onCreateInputConnection(editorInfo);
assertThat(editableInputConnection.beginBatchEdit()).isTrue();
assertThat(editableInputConnection.beginBatchEdit()).isTrue();
assertThat(editableInputConnection.endBatchEdit()).isTrue();
assertThat(editableInputConnection.endBatchEdit()).isFalse(); // (*)
assertThat(editableInputConnection.endBatchEdit()).isFalse();
However, the last assertion marked with (*) actually fails due to an
off-by-one bug. This CL finally fixes it.
The risk of app compat breakages because of fixing this long standing
bug is supposed to be low, mainly because:
* the system has not relied on this return value yet.
* Widgets like WebView have correctly implemented this API.
* IME has always received true no matter what the app returned, which
is the same behavior as other async InputConnection APIs.
This CL adds several notes to InputConnection#endBatchEdit() document
to help developers correctly implement and use this API.
[1]: I1ec5518fdc16fb0551fbce9d13f5d92eb4bc78c0
c478c171e9
Fix: 209958658
Fix: 210165648
Test: atest -c CtsInputMethodTestCases:EditTextImeSupportTest
Change-Id: Ibc40072fa11a4d6e3c24b8d7860c914ccdbcbc8a
Merged-In: Ibc40072fa11a4d6e3c24b8d7860c914ccdbcbc8a
(cherry picked from commit beda2b7f76)
Fixes a case where the SurfaceView is stuck with a wrong
scale.
Destination frame scales the buffer to the SurfaceView
fixed size. Currently the initial destination frame is
applied when the first buffer is acquired by BBQ. The
transaction is sent via the BBQ apply token.
Meanwhile if the client updates the SurfaceView fixed
size, the SurfaceView will apply the transaction via
the SCC apply token.
This can cause destframe changes to be applied out of
order causing the app to be stuck with the wrong
scale.
Bug: 195443440
Test: atest BLASTBufferQueueTest
Test: repro steps from bug
Change-Id: Ibf53a0efdebb87291d081e48633c373a98d347b1
Merged-In: Ibf53a0efdebb87291d081e48633c373a98d347b1
This is a follow up CL to our previous CL [1], which had an off-by-one
bug when determining the return value of
EditableInputConnection#endBatchEdit().
According to the API document of InputConnection#endBatchEdit(), the
following test should pass.
EditText editText = new EditText(context);
EditorInfo editorInfo = new EditorInfo();
InputConnection editableInputConnection =
editText.onCreateInputConnection(editorInfo);
assertThat(editableInputConnection.beginBatchEdit()).isTrue();
assertThat(editableInputConnection.beginBatchEdit()).isTrue();
assertThat(editableInputConnection.endBatchEdit()).isTrue();
assertThat(editableInputConnection.endBatchEdit()).isFalse(); // (*)
assertThat(editableInputConnection.endBatchEdit()).isFalse();
However, the last assertion marked with (*) actually fails due to an
off-by-one bug. This CL finally fixes it.
The risk of app compat breakages because of fixing this long standing
bug is supposed to be low, mainly because:
* the system has not relied on this return value yet.
* Widgets like WebView have correctly implemented this API.
* IME has always received true no matter what the app returned, which
is the same behavior as other async InputConnection APIs.
This CL adds several notes to InputConnection#endBatchEdit() document
to help developers correctly implement and use this API.
[1]: I1ec5518fdc16fb0551fbce9d13f5d92eb4bc78c0
c478c171e9
Fix: 209958658
Fix: 210165648
Test: atest -c CtsInputMethodTestCases:EditTextImeSupportTest
Change-Id: Ibc40072fa11a4d6e3c24b8d7860c914ccdbcbc8a
* changes:
Plumb support for rendering A8 in Vulkan
Plumb through A8 for GL/EGL
Add COLOR_MODE_A8/ColorMode::A8
Treat AHARDWAREBUFFER_FORMAT_R8_UNORM as kAlpha_8_SkAlphaType
The system received the same multiple translation responses in a very
short time. We use a isShowingTranslation flag to determine if the
duplicated responses to call onShowTranslation. However the
isShowingTransation flag is set in a post runnable, this may cause the
system allow the duplicate responses can call onShowTranslation
because the isShowingTransaltion isn't set true yet.
Use multiple flags isShowingTranslation and a new isRunningAnimation
to check if the same translation response should skip to call
onShowTranslation.
Bug: 207457172
Test: manual
Test: atest CtsTranslationTestCases
Change-Id: I7003b7f49fc0a8ce2e909228bcb89acedee6d3d0
1. If a relayout requested blast sync but we canceled the draw and
schedule it for later, the next draw won't use blast sync. This change
makes sure we use blast sync on the next performTraversal
2. Remove mReportDrawToWm and always send transaction to WMS to apply.
This is because there could be multiple report draws in a row and we'd
unset the flag after the first and not send the other transactions to
WMS
Test: Screen rotation no flicker with rounded corners
Change-Id: I8bf3881dfcdd2e54f0ec78f9fb695c76385f4228
Eight constructor parameters is a lot for a public Java constructor.
So adding a Builder for this class to reduce the likelihood of
mistaking one int for another.
Bug: 207683571
Test: a11y CTS & unit tests
Change-Id: I9d779228ee4c21728451195541f629c08ae275c4
