Developers can control the backend in the following ways:
* **Do nothing**: Impeller with Vulkan is used where Vulkan is available with a fallback to Skia with OpenGL.
* **In `AndroidManifest.xml`, specify `io.flutter.embedding.android.EnableImpeller` as `false`**: Skia with OpenGL is used.
* **On the command line, specify `--no-enable-impeller`**: Skia with OpenGL is used.
Manifest options will take priority command line options when there is a conflict. This matches iOS behavior per https://github.com/flutter/flutter/issues/124049 (closed as WAI).
Fixes https://github.com/flutter/flutter/issues/149360
In https://github.com/flutter/engine/pull/53280, I'm adding
lifecycle-aware methods to `SurfaceProducer`.
That means, in order to test that it WAI, we'll need to be running in a
simulated activity, and be able to switch scenario states (i.e. to
`RESUMED`). This was mentioned as well in
https://github.com/flutter/flutter/issues/133151 as being something we
want to do.
This PR adds a `FlutterEngineRule`, which allows the creation of a
"real" `FlutterEngine` and an `Intent` that can power
`AndroidScenarioRule<FlutterActivity>`. I felt bad doing all of this
work for a single `@Test`, so I also refactored the rest of the file and
cleaned things up a bit.
That said, I'm happy to revert or make changes if we liked how things
were setup before.
Revert label failed due to conflicts
`FlutterFragmentTest.java` was the only file that had merge issues, everything else is the output of `git revert 802e5d2cd3c9e73f336e3fe43487b64a5fdf98d8`
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Android add-to-app apps now support predictive back when going between Activities or back to the home screen. Predictive back route transitions within the Flutter part of the app are not yet supported.
Upgrades every `androidx` dependency in the `src/third_party/android_embedding_dependencies` bundle to the latest version, except the `lifecycle` group*. Tested running a couple of apps as well because when updating these dependencies in the past I've been able to build the engine but then flutter run fail when trying to run an app.
Fixes https://github.com/flutter/flutter/issues/129307, also unblocks a feature that will eventually be needed for Scribe.
[*]`2.8.0` is the latest there, but I ran into an issue with dexing when I tried to upgrade, due to b/336164417, an AGP bug that had its fix backported to all >`8.0.0` versions, but we still support less than that so we will have to wait on that upgrade.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Reverts: flutter/engine#51229
Initiated by: gmackall
Reason for reverting: blocking engine->framework roll (I missed some framework code referencing the v1 embedding).
Original PR Author: gmackall
Reviewed By: {matanlurey, reidbaker}
This change reverts the following previous change:
Fixes https://github.com/flutter/flutter/issues/143531
Also fixes a random typo I found
~TODO to test this~ (no more todo):
-~test the framework against this as well, probably with a dummy PR changing the engine commit to my branch if this is possible~ not possible, made a best effort removal of framework code in https://github.com/flutter/flutter/pull/144726.
-~figure out if the old embedding is used in g3 at all~ removed all uses
-~figure out exactly what the ShimPluginRegistry/ShimRegistrar are doing, and if fully deleting them was right~ (see https://github.com/flutter/engine/pull/51229#issuecomment-1981757743)
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Support for Android's predictive back feature on internal Flutter routes. Reports predictive back gestures to the framework (where supported by the system).
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.
