Reverts flutter/engine#51391
Reason for revert: b/330184547 - I believe there is a good chance that the investigation on that issue was not really adequate to justify this revert, but this change can be easily relanded if reverting this was the wrong choice.
Consider this scenario: In an add-to-app context, where multiple Flutter activities share the same engine, a situation occurs. When navigating from FlutterActivity1 to FlutterActivity2, the Flutter view associated with FlutterActivity1 is detached from the engine. Then, the Flutter view of FlutterActivity2 is attached. Upon navigating back to FlutterActivity1, its Flutter view is re-attached to the shared engine.
The expected behavior is: When a Flutter view detaches from the shared engine, the associated surface should be released. When the Flutter view re-attaches, a new surface should be created.
After #47358, no new surface is created when the Flutter view is attached again. This results in the Flutter view having no underlying surface, which causes the page to appear blank or freeze without responding.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
We originally added this cleanup code to work around a Samsung-specific
Android 14 bug where after resuming an application any ImageReaders are
busted. According to the Android team what Samsung is doing is a
violation of the "spec".
The fix ended up breaking VirtualDisplay platform views after a
suspend/resume because the surface we pass to the VirtualDisplay is no
longer valid after the resume and we have no way of fixing that.
This PR removes the Samsung-specific hacky fix, restoring the behaviour
of VirtualDisplay backed platform views.
We have an internal bug with Samsung to address the root cause.
Updates the linting script to ban the use of `VERSION_CODES`.
We currently have a mish-mash of using the integers, using `VERSION_CODES`, and even how we import the version codes. This makes it more confusing when doing things like #51070 - I think it is clearer to see `22` than `LOLLIPOP_MR1`.
I'd like to get LGTM (or at least no opinion) from all the requested reviewers here.
This reverts commit 98485b3f82fec45a6a0ac932c3c20285a9a14e02.
Reverted in https://github.com/flutter/engine/pull/51056 because it
caused failures in the framework. No changes, but framework test has
been updated to use an actual robolectric implementation to avoid those
failures.
This should not land until
https://github.com/flutter/flutter/pull/144348 has landed in the
framework.
@gaaclarke @johnmccutchan fyi
Reverts flutter/engine#49996
Initiated by: gmackall
Reason for reverting: b/326363243
Original PR Author: gmackall
Reviewed By: {johnmccutchan, reidbaker}
This change reverts the following previous change:
Original Description:
Fixes https://github.com/flutter/flutter/issues/106449. Changes it to a static proxy, as the comment recommended. This does mean we will have to update it to override new methods as they are added to the interface when updating the version of the Android sdk we use.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
- Close all ImageReaders and Images when we get an onTrimMemory
callback.
- Remove the first frame fix based around caching the last image
displayed because it isn't safe to do on some platforms. Leave a TODO to
revisit this.
We have seen some reports of platform views not working after an
application is backgrounded and then resumed. According to Android GPU
folks ImageReader/Image/HardwareBuffers should be valid after an
application has been resumed. However on Samsung we know that isn't the
case and there are (unconfirmed) reports of it also impacting Pixel
devices.
Should fix https://github.com/flutter/flutter/issues/142978 and
https://github.com/flutter/flutter/issues/139039
Also fixes https://github.com/flutter/flutter/issues/143720
## Description
This PR fixes an issue where keystrokes aren't received on Android
devices with physical keyboards (e.g. rugged Zebra devices) when
`keyboardType` is set to `TextInputType.none` on a `TextField`.
The logic in `setTextInputClient` and `canShowTextInput` created an
`inputTarget` with `InputTarget.Type.NO_TARGET` which caused the [input
connection to short
circuit](https://github.com/flutter/engine/blob/main/shell/platform/android/io/flutter/plugin/editing/TextInputPlugin.java#L296)
and not be established.
Bug introduction PR: https://github.com/flutter/engine/pull/26585
## Related Issue
https://github.com/flutter/flutter/issues/89983
## Unit Test Notes
- The existing `showTextInput_textInputTypeNone()` stays green after
update.
- `inputConnection_textInputTypeNone()` updated to `assertNotNull`. I
would make this more specific, but this is my first venture into the
Flutter engine and don't know enough about those connection attributes.
## Demo
Video below with Zebra MC9300 device. This issue can also be reproduced
in a standard android emulator. Simply add a `TextField`, configure
`keyboardType` to be `TextInputType.none` and attempt to enter text
after running and giving focus to textfield.
Before
https://github.com/flutter/engine/assets/1988098/348ca061-b8b9-4483-956e-0732c1238207
After
https://github.com/flutter/engine/assets/1988098/b65c7251-59b4-4c73-9b85-7ac03f47a7e4
## Pre-launch Checklist
- [x] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [x] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [x] I read and followed the [Flutter Style Guide] and the [C++,
Objective-C, Java style guides].
- [x] I listed at least one issue that this PR fixes in the description
above.
- [ ] I added new tests to check the change I am making or feature I am
adding, or the PR is [test-exempt]. See [testing the engine] for
instructions on writing and running engine tests.
- [ ] I updated/added relevant documentation (doc comments with `///`).
- [x] I signed the [CLA].
- [x] All existing and new tests are passing.
- ImageReaderSurfaceProducer no longer drops frames when the producer and the consumers are up to two frames out of sync.
- Have the native C++ side of the Android external textures check if a new frame has been pushed and that the texture needs to be updated. This avoids having to schedule a task on the raster thread for each updated texture.
- Notify the engine earlier that a frame is needed when updating a TLHC texture.
- Re-land fix: Don't close the last dequeued from image reader until the dequeued image is no longer used.
- ImageReaderSurfaceProducer no longer drops frames when the producer
and the consumers are up to two frames out of sync.
- Have the native C++ side of the Android external textures check if a
new frame has been pushed and that the texture needs to be updated. This
avoids having to schedule a task on the raster thread for each updated
texture.
- Notify the engine earlier that a frame is needed when updating a TLHC
texture.
- Reland fix: Call SurfaceTextureExternalTexture::ProcessFrame if
dl_image_ is null.
Reverts flutter/engine#50033
Initiated by: zanderso
This change reverts the following previous change:
Original Description:
- ImageReaderSurfaceProducer no longer drops frames when the producer and the consumers are up to two frames out of sync.
- Have the native C++ side of the Android external textures check if a new frame has been pushed and that the texture needs to be updated. This avoids having to schedule a task on the raster thread for each updated texture.
- Notify the engine earlier that a frame is needed when updating a TLHC texture.
- ImageReaderSurfaceProducer no longer drops frames when the producer
and the consumers are up to two frames out of sync.
- Have the native C++ side of the Android external textures check if a
new frame has been pushed and that the texture needs to be updated. This
avoids having to schedule a task on the raster thread for each updated
texture.
- Notify the engine earlier that a frame is needed when updating a TLHC
texture.
## Description
This PR fixes a `NullPointerException` thrown from `KeyEmbedderResponder` when pressing a key during a hot restart (at this time the framework might not be ready and null reply is sent back).
## Related Issue
Fixes https://github.com/flutter/flutter/issues/141662.
## Tests
Adds 1 test.
## Description
This PR calls Android API `InputMethodManager.restartInput` to reset IMEs internal states. Otherwise some IMEs (Gboard for instance) keep reacting based on the previous input configuration until a new configuration is set.
- On Android native, `restartInput` is called in several places, for instance in f219798774/android/widget/TextView.java (L2458).
- On Compose, https://github.com/flutter/flutter/issues/70546#issuecomment-1088345561 pointed out where it is called.
- On Flutter, it is called at some point but mainly when another `TextField` is focused (it is mainly called in `setTextInputEditingState`).
## Related Issue
Fixes https://github.com/flutter/flutter/issues/70546.
## Tests
Adds 1 test.
- Enable ImageReader/SurfaceProducer backends for Android >= 29.
- This removes the need for a weird Android 29-specific fix in
SurfaceTexturePlatformViewRenderTarget.
- Now that we don't need the weird fix we can simplify the
PlatformViewRenderTarget interface.
This change ensures that we first set the default buffer size on the
underlying SurfaceTexture before creating the Surface for it.
This fixes a bug that only occurs on Android devices running 28 or
older: see https://github.com/flutter/flutter/issues/141068.
This also removes some unnecessary init code and cleans up tests.
The following sequence of events would lead to a crash:
- Reader A is created.
- Reader A produces a frame (A0)
- Texture is resized.
- Reader B is created and reader A is scheduled to be closed.
- Reader A produces a frame (A1). This is skipped.
- Reader A is closed.
- Frame A0 is acquired.
Because we closed Reader A the frame A0 is invalid.
The fix is to not close Reader A when it is the last reader to produce a
frame.
Fixes internal bug b/318458306
related issue https://github.com/flutter/flutter/issues/111268,
https://github.com/flutter/flutter/issues/106190
### Motivation:
- At https://github.com/flutter/flutter/issues/111268, we found that
Android PlatformView scrolls slowly after #34182 commit
### Modification:
- Makes `PlatformViewsController` view to use `tracked event`'s action &
pointer count
### Result:
- Now PlatformView scrolls not slowly
- Close https://github.com/flutter/flutter/issues/111268,
https://github.com/flutter/flutter/issues/106190
- [ ] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [ ] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [ ] I read and followed the [Flutter Style Guide], including [Features
we expect every widget to implement].
- [x] I signed the [CLA].
- [x] I listed at least one issue that this PR fixes in the description
above.
- [ ] I updated/added relevant documentation (doc comments with `///`).
- [x] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [x] All existing and new tests are passing.
Co-authored-by: John McCutchan <john@johnmccutchan.com>
The `SurfaceProducer` interface exposes only exposes a Surface to render
on, abstracting away the consumer side of the external texture.
The `ImageReaderSurfaceProducer` implementation of this interface is
included as well as a basic test of that code.
Also, a small refactor so that `ImageTexture` and
`ImageReaderSurfaceProducer` can use the same native C++ code in the
engine.
Subsequent CLs will need to address the following:
- A SurfaceTextureSurfaceProducer (your eyes are probably bleeding from
that name) implementation is needed so we can support GL based systems.
- Update Platform Views to use this new SurfaceProducer type instead of
the legacy types.
- Deprecate SurfaceTexture and ImageTexture external texture types.
Related issue
[#139702](https://github.com/flutter/flutter/issues/139702)
Accompanying framework PR: https://github.com/flutter/flutter/pull/138331
This PR implements support for exposing `SemanticsProperties.identifier` on Android as `resource-id`. Mainly targeted at https://github.com/flutter/flutter/issues/17988. Would also fix https://github.com/flutter/flutter/issues/issues/137735 but it was marked as duplicate. Anyway, there's a lot of context in that issue.
This PR requires changing the `SemanticsUpdateBuilder` interface (defined in engine) that framework depends on, so it requires introducing a temporary API ([see question I asked on Discord](https://discord.com/channels/608014603317936148/608018585025118217/1174845658033819729) to learn more about this approach).
Steps:
**part 1: [engine] add `SemanticsUpdateBuilderNew`** <-- we are here
part 2: [flutter] use `SemanticsUpdateBuilderNew`
part 3: [engine] update `SemanticsUpdateBuilder` to be the same as `SemanticsUpdateBuilderNew`*
part 4: [flutter] use (now updated) `SemanticsUpdateBuilder` again.
part 5: [engine] remove `SemanticsBuilderNew`
I'd like to do these changes first, and only then continue with [the proper framework PR](https://github.com/flutter/flutter/pull/138331).
*More specifically: update `SemanticsUpdateBuilder.updateNode()` to be the same as `SemanticsUpdateBuilderNew.updateNode()`. Number of arguments that function takes is the only change.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Adds a check to retrieve explicit text from Clipboard items via [`getText`](https://developer.android.com/reference/android/content/ClipData.Item#getText()) before attempting to retrieve data if the Clipboard item (`ClipData.Item`) has an associated URI. Also adds more error handling for edge cases concerning URIs (the URI not having the content scheme or being null).
Fixes https://github.com/flutter/flutter/issues/74320. Some content providers will not send URIs containing the `text/*` pattern or have the content scheme (`content://`), but ultimately we should expect Clipboard items to either fall **not** into one of those categories or have an explicit textual value available via `getText`. In case this is not true, though, checks for non-content URIs and null URIs are added, as well :)
Tested on a Samsung tablet with pasting from MS Word, MS Excel, and Samsung Notes.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
## Description
This PR adds support for the PlatformChannel `Share.invoke` message on Android (before this PR it is only supported on iOS).
## Related Issue
Engine side for https://github.com/flutter/flutter/issues/138728
## Tests
Adds 2 tests.
The difference between this PR and the original is the change to the `AndroidManifest.xml`. For context, right before the original PR landed, [a change to upgrade the target sdk](https://github.com/flutter/engine/pull/47683) in the manifest from 31 to 33 landed. It also removed the lint complaining about using an old target sdk version from the baseline lint file. So this change upgrading the sdk, but not the target sdk in the manifest, triggered the lint again.
For the rest of the PR, [see the description of the original PR](https://github.com/flutter/engine/pull/47609).
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Reverts flutter/engine#47609
Initiated by: zanderso
This change reverts the following previous change:
Original Description:
~**This should not land until https://github.com/flutter/buildroot/pull/790 (re)lands, and I swap the buildroot url back to the latest commit.**~ ~Reland of PR to update buildroot at https://github.com/flutter/buildroot/pull/792. ~ <- landed, and changed the buildroot commit to the latest in DEPS
Upgrades to android api 34
Also:
1. Upgrades to java 17 in DEPS/ci, because the linter now requires it.
2. Stops running some roboelectric tests on android apis 16-18, because Roboelectric indicated those versions were unsupported and we don't support them either.
3. Applies the four trivial new suggestions from the newer linter.
4. Updates the baseline lint to include the new non-trivial lint ([fixed in a different PR](https://github.com/flutter/engine/pull/47817/files)).
5. Changes some instances where we were hardcoding android apis as numbers (e.g. `sdk = 16') to use version codes (see the [comment below](https://github.com/flutter/engine/pull/47609#issuecomment-1800308658)).
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
## Description
Before we deprecate the `RawKeyEvent` code, it needs to provide parity in functionality. One thing that is missing is the `eventSource` field from the `RawKeyEventDataAndroid` class, which provides the device type for the event.
See https://developer.android.com/reference/android/view/InputDevice#SOURCE_KEYBOARD for an example.
This PR implements that support, and sets the source to `KeyEventDeviceType.keyboard` for platforms that don't provide this information. The main thing it does is add the enum `KeyEventDeviceType`, and a new field `KeyData.deviceType`.
## Related Issues
- https://github.com/flutter/flutter/issues/136419
## Tests
- Updated tests to also read/write/verify this property.
When we enter hybrid composition mode we 'pause' the default RenderSurface (implemented by SurfaceView or TextureView) and swap to an ImageReader based RenderSurface.
When we return from hybrid composition mode we recreate and re-initialize the real RenderSurface as if it was being used for the first time.
This broke Platform Views in an internal app b/306122497 because we would incorrectly tell the texture to attach when it was never detached.
This CL changes the protocol so that when we return from hybrid composition mode we only swap the RenderSurface and do not re-create it. This avoids doing a bunch of unnecessary work and fixes the logic error of re-attaching textures that were never detached.
*Replace this paragraph with a description of what this PR is changing or adding, and why. Consider including before/after screenshots.*
*List which issues are fixed by this PR. You must list at least one issue.*
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
- Refactor the fence waiting code to only wait on Android >= 33.
- Log a warning message once per image rendering target on Android >= 29 && < 33.
- Add a simple unit test of ImageReaderPlatformViewRenderTargets.
Fixes internal bug b/303652511 and includes a regression test.
The TL;DR of the bug is that when re-launching a singleton-cached-engine
Flutter activity using FLAG_ACTIVITY_CLEAR_TASK, the teardown of the
previous Flutter activity interleaves with the creation of the new
Flutter activity, resulting in the Flutter engine ending up incorrectly
in the AppLifecycleState.detached state. This then results in the app
being completely unresponsive because Flutter doesn't draw frames in
this state. I don't know if the issue is reproducible in production
under normal user operation, but I'm concerned it very easily could be.
There's also nothing stopping other apps or Android system code from
launching an app using this flag.
