## 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.
The size the engine recieves from the `AndroidSurfaceVulkanImpeller::OnScreenSurfaceResize` appears to be correct in the case of window rotation. Use this instead of physical surface properties to set the swapchain image size.
Querying the physical surface properties seems to have some additional non-deterministic delay. This means that querying the properties during a window rotation will frequently return old values.
Fixes https://github.com/flutter/flutter/issues/138780
Fixes https://github.com/flutter/flutter/issues/132708
Reland of: https://github.com/flutter/engine/pull/50139
Metal does not seem to like it when we collect 50+ command buffers at once. Adjust the aiks context logic to regularly flush the cmd buffers.
Reverts flutter/engine#50139
Initiated by: jonahwilliams
This change reverts the following previous change:
Original Description:
The Impeller Vulkan backend benefits from batching submission to the vk graphics queue. Managing this automatically is non-trivial and adds surprising/fragile thread based behavior, see: https://github.com/flutter/engine/pull/49870
Instead, introduce an impeller::CommandQueue object that command buffers must be submitted to in lieu of CommandBuffer->Submit, which has been made private.
TLDR
old
```c++
buffer->Submit();
```
new
```c++
context.GetQueue()->Submit({buffer});
```
The Metal and GLES implementations internally just call the private CommandBuffer->Submit, though there may be future opportunities to simplify here. The Vulkan implementation is where the meat is.
Aiks takes advantage of this by storing all command buffers on the aiks context while rendering a frame, and then performing one submit in aiks_context render. I don't think this will introduce any thread safety problems, as we don't guarantee much about aiks context - nor do we use it in a multithreaded context as far as I know.
Other tasks such as image upload still just directly submit their command buffers via the queue.
Fixes https://github.com/flutter/flutter/issues/141123
The Impeller Vulkan backend benefits from batching submission to the vk graphics queue. Managing this automatically is non-trivial and adds surprising/fragile thread based behavior, see: https://github.com/flutter/engine/pull/49870
Instead, introduce an impeller::CommandQueue object that command buffers must be submitted to in lieu of CommandBuffer->Submit, which has been made private.
TLDR
old
```c++
buffer->Submit();
```
new
```c++
context.GetQueue()->Submit({buffer});
```
The Metal and GLES implementations internally just call the private CommandBuffer->Submit, though there may be future opportunities to simplify here. The Vulkan implementation is where the meat is.
Aiks takes advantage of this by storing all command buffers on the aiks context while rendering a frame, and then performing one submit in aiks_context render. I don't think this will introduce any thread safety problems, as we don't guarantee much about aiks context - nor do we use it in a multithreaded context as far as I know.
Other tasks such as image upload still just directly submit their command buffers via the queue.
Fixes https://github.com/flutter/flutter/issues/141123
- 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.
Reverts flutter/engine#50028
Initiated by: jonahwilliams
This change reverts the following previous change:
Original Description:
Once a hardware buffer has been imported (a VkImage created for it), we don't ever need to re-create a VkImage, even when the contents change. The same hardware buffer can be identified by ID. Part of https://github.com/flutter/flutter/issues/142153
Otherwise we spend a lot of time re-creating VkImages:
Draft is here, but is currently leaky: https://github.com/flutter/engine/pull/50028
We only need something like a LRU with the max image size (seems to be 3 for me). This does log locally that I'm not calling close correctly:
```
E/flutter ( 5580): [ERROR:flutter/shell/platform/android/image_external_texture_vk.cc(51)] Size: 3
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
```
FYI @johnmccutchan
Once a hardware buffer has been imported (a VkImage created for it), we don't ever need to re-create a VkImage, even when the contents change. The same hardware buffer can be identified by ID. Part of https://github.com/flutter/flutter/issues/142153
Otherwise we spend a lot of time re-creating VkImages:
Draft is here, but is currently leaky: https://github.com/flutter/engine/pull/50028
We only need something like a LRU with the max image size (seems to be 3 for me). This does log locally that I'm not calling close correctly:
```
E/flutter ( 5580): [ERROR:flutter/shell/platform/android/image_external_texture_vk.cc(51)] Size: 3
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
W/System ( 5580): A resource failed to call HardwareBuffer.close.
```
FYI @johnmccutchan
Fixes https://github.com/flutter/flutter/issues/141571
Shell::Screenshot was impelemnted in a Skia-only way and would crash when invoked. Adds test coverage for the breaking path on iOS that ends up calling `FlutterView drawLayer`.
- 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.
The Impeller context requires us to call Shutdown to ensure that all of its spawned worker threads are joined, ensuring that the raster thread retains the last reference. Without this, we may either destroy parts of the context to early, or attempt to join into a worker thread which will fail.
The original change was reverted as it broke the GPU tracer reset logic. The previous logic assumed that the first started command buffer would also be the first submitted command buffer. With the direct encoding, this is no longer the case - so we shift the logic so that we reset query pools once at startup and then after the queries are finished being recorded.
This might actually be better in general since we should be doing less work in the frame workload.
## 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.
All of these are non-semantics changing and all were auto-applied by
IntelliJ:
- Make always `final` stuff final
- Avoid unnecessary casts
- Annotate `@NonNull` overrides
- Avoid initializing callbacks outside of the constructor, and use Java
lambdas when applicable
- Avoid cases where something is known to be non-null or non-false
- Use `<>` when applicable
Closes https://github.com/flutter/flutter/issues/141043.
Nothing in this change should impact:
- End-user apps
- Testing and/or CI
I've added what I believe is the minimum required to get a reasonable
Android Studio experience with the `shell/platform/android` folder. More
could definitely be done, but this unblocks me (i.e.
https://github.com/flutter/flutter/issues/139702) and adds instructions
for the next person.
_I'm open to suggestions on how to improve this further, but unless they
are critical, I'd rather land this as-is and review your PRs tweaking my
documentation further (I have limited time to work exclusively on
docs)._
---
Example after this:
- 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
Android Platform Views process MotionEvents in a complicated way:
1. MotionEvent is captured and delivered to
PlatformViewWrapper.onTouchEvent (TLHC) or
FlutterMutatorView.onTouchEvent (HC)
2. MotionEvent is transformed by the AndroidTouchProcessor into a
PointerEvent
3. AndroidTouchProcessor sends the PointerEvent over the
PlatformViewChannel
4. Framework processes the PointerEvent
5. Framework sends the PointerEvent over the PlatformViewChannel.
6. in PlatformViewsController.onTouch a new MotionEvent is synthesized
7. The MotionEvent is delivered to the platform view
After step (6) the MotionEvent will fail Verification
(`android.hardware.input.InputManager.verifyInputEvent`).
The fix requires that in step (6) we use the original motion event
delivered in step (1) instead of synthesizing a new instance.
This PR adds a new way to define scoped trace events in Java, using the try-with-resource construct. This makes code simpler to read, and less error-prone.
Before:
```java
try {
TraceSection.begin("name");
// ....
} finally {
TraceSection.end();
}
```
Now:
```java
try (TraceSection e = TraceSection.scoped("name")) {
// ...
}
```
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
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)
Support framebuffer fetch on devices that have the extension VK_ARM_RASTERIZATION_ORDER_ATTACHMENT_ACCESS which gives us a fairly easy way to add subpass self dependencies.
Part of https://github.com/flutter/flutter/issues/120223
This PR adds multiview support for `ExternalViewEmbedder`.
## Nomenclature
The term **view** can be ambiguous in `ExternalViewEmbedder`, and therefore the following terms are used:
* A **native view** refers to the final drawing surface that to composite layers to. It is the "view" used in other places of the engine, such as `Shell::AddView`.
* A **platform view** refers a platform view, a layer that holds content to be embedded.
## Change
The lifecycle of `ExternalViewEmbedder` is changed:
<table>
<thead>
<tr>
<th>Before PR</th>
<th>After PR</th>
<th>How it's called</th>
</tr>
</thead>
<tbody>
<tr>
<td rowspan=2>BeginFrame</td>
<td>BeginFrame</td>
<td>Once per frame</td>
</tr>
<tr>
<td>PrepareFlutterView</td>
<td>Once per flutter view</td>
</tr>
<tr>
<td>SubmitFrame</td>
<td>SubmitFlutterView (renamed)</td>
<td>Once per flutter view</td>
</tr>
<tr>
<td>EndFrame</td>
<td>EndFrame (unchanged)</td>
<td>Once per frame</td>
</tr>
</tbody>
</table>
* `BeginFrame` should perform per-frame actions, such as merge-unmerging threads.
* `PrepareView` should perform per-native-view preparations, such as recording the view ID and view size.
This change is necessary because some actions in `PrepareView` needs to be refreshed at the beginning of drawing every native view.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
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.
