This PR connects the view ID provided by the rasterizer to `EmbedderExternalViewEmbedder`'s presenting call (see `embedder_external_view_embedder.cc`).
This PR also contains a refactor (which actually takes the majority of LOC) that moves the specification of view ID from `PrepareFlutterView` to `SubmitFlutterView`. The `flutter_view_id` parameter in `PrepareFlutterView` was added in https://github.com/flutter/engine/pull/46169. It turns out that we don't need the view ID throughout the preparation phase, so we can delay the specification to submission, which makes it feel cleaner.
### Tests
Existing tests are changed to verify that `SubmitFlutterView` receive the correct view ID.
The feature that `EmbedderExternalViewEmbedder` sends the view ID to the presenting API is not tested for now, because `EmbedderExternalViewEmbedder` is typically tested in `embedder_unittests`, but it requires the embedder API `AddView`. It will be tested in later changes to `EmbedderExternalViewEmbedder`.
[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
This reverts commit 037aa6b4caa6a3a726e67e519324b2c0a1ec274a.
The original cause of the revert was a flake introduced because the unit-test could request a frame from the Choreographer if it ran long enough. The availability checks in the choreographer were inaccurate after we intentionally backed out of using the Callback32 variant on 32 bit platforms.
The new tests didn't catch it because of an unrelated issue. In the first version of the patch for review, the proc table was only supposed to run on API levels 29 and above. When @dnfield requested we also get rid of the NDK helpers, the choreographer and additional utilities were added. But the API level gate in the new test harness wasn't removed. This made the tests be skipped. That gate has been removed entirely now. The error that cause the revert because of flakiness will now be a reliable failure.
Only available on Android device API levels >= 29. Proc table is setup has versioning checks. All handles are type safe. Collection of handles takes into account cleanup tasks (like reparenting surface controls). The proc table contains code duplicated in ndk_helpers and I will remove that in favor of this in a subsequent patch.
Part of https://github.com/flutter/engine/pull/51213 being chopped up.
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.
This does not fix the emulator weirdness!
Today we automatically select the first memory type index requested by an AHB. The device in question may lack that memory type index, so we can then fail to import the AHB. Additionally, if we do fail we need to ensure that we don't attempt to display the texture.
Also doesn't compile the TU on non-Android platforms.
Part of https://github.com/flutter/engine/pull/51213 being chopped up.
No change in functionality. Just renames and moves stuff around.
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 patch rounds out support for importing Android Hardware Buffers as Vulkan
images and sampling from them.
Not all Android Hardware Buffers are in formats that Vulkan (let alone Impeller)
understands. Some YUV textures have formats with no equivalent `vk::Format` enum
and need extra information on how to sample from them.
This patch adds support for correctly importing and sampling from such formats.
There are severe restrictions on how sampling from such external formats works.
For one, it isn’t possible to assign a combined image sampler in the render
pass. The pipeline itself needs to be rebuilt to reference a specially created
immutable sampler. This immutable sampler is a combination of the usual
information present in an Impeller SamplerDescriptor as well as a custom
“conversion” object obtained while importing the Android Hardware Buffer.
There is no way to predict what conversion object will be necessary ahead of
time as this will depend on the source of the Android Hardware Buffers and is
likely different for different video feeds, camera sources, and other Android
Hardware Buffer texture sources.
To handle this uncertainty, a new pipeline variant with a JIT determined
immutable sampler will be hashed and cached before being used in a render pass.
The number of pipeline variants created just-in-time will depend on the number
of sampler variants used in the render pass to sample from wrapped Image. For
instance, specifying a sampler with a different address mode will likely result
in a new pipeline variant being created.
In most cases however, there will just be one or two additional pipeline
variants per application. Impellers sampler diversity is very low with most
samplers being the usual NN samplers. It may be possible to preload even this
pipeline by trying known conversions. As said previously, there can only be a
handful of these conversions.
More restrictions on sampling from such images includes being limited to
`VK_FILTER_LINEAR` without additional format and extension wrangling and
performance penalties.
Fixes https://github.com/flutter/flutter/issues/142082.
This was introduced in #51070 - my grepping for `LOLLIPOP` was too aggressive, and apparently the linter didn't catch this. I think it's just a bug in the linter.
Fixes b/327717572, because Google internal tests caught this.
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
1. Makes it possible to implement Impeller Vulkan -> Skia fallback.
2. Fixes https://github.com/flutter/flutter/issues/143871
3. Fixes https://github.com/flutter/flutter/issues/143873
4. Work towards https://github.com/flutter/flutter/issues/137798
Combines AndroidRenderingAPI + enable_impeller into a 4 values enum that describes all combinations of rendering behavior: ImpellerVulkan, ImpellerOpenGLES, SkiaOpenGLES, Software.
Updates the fallback behavior to happen in flutter_main. This allows us to change the value of Settings.enable_impeller to support an Impeller -> Skia fallback.
@jason-simmons @jiahaog fyi
I need to figure out a test for this still but it seems to work. Hot restart is kind of a mess though, because `Engine::Restart` nulls out the asset manager it ends up reloading the font collection for every engine after a restart. But we separately need to fix hot restart, it's not very usable on the example app
Fixes https://github.com/flutter/flutter/issues/143701
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
Without this, the EmbedderExternalViewEmbedder's call to SurfaceFrame::Submit will render an empty display list that will overwrite the output rendered by the external view embedder's layers.
See https://github.com/flutter/flutter/issues/143387
Adds more dynamic method lookups in service of https://github.com/flutter/flutter/issues/143105
Moves the TU out to FML so that Impeller can more easily use it.
Adds checking on `AHardwareBuffer_getId` so that it checks the return value before returning what is potentially garbage.
Adds some smoke tests to make sure these things actually work/look up meaningful symbols. Test is in the shell because we have testing infra for this kind of thing there.
The queue submit thread could sometimes call vkQueuePresentKHR while the raster thread is calling vkAcquireNextImageKHR. The simultaneous use of the swapchain on multiple threads violates Vulkan threading rules.
