The previous logic allowed proxying for any view that belonged to one of the platform views' virtual displays which may lead to us allowing proxying for a view that the platform view isn't allowing proxying for, previous logic also didn't account for unattached views.
This change instead delegates the decision to the platform view.
We use the fact that each virtual display has its unique context to associate any view with its relevant virtual display.
A nice side effect of calling the platform view's checkInputConnectionProxy for webviews is that the plugin now has a way to get a handle to the ThreadedInputConnectionProxyView, which may be useful for getting keyboard working on webview's prior to Android N.
* Added unit tests for the ios code.
* Moved the tests to live next to the source.
* Added mocking library.
* Fixed formatting and removed third_party from the format check.
* fixed formatting 2
* Removed ocmock from third_party.
* Added ocmock to third_party, compile from source.
* removed ocmock from license checking
* updated licenses_flutter
* updated tool_signature
Add views that are added directly to a platform view's window as siblings to the platform view's container view, rather than as children of a full screen container.
This prevents a false-negative for a visibility check from a specific ads SDK (Teads), which [reported the following warning](https://github.com/flutter/flutter/issues/12114#issuecomment-500906158):
```
W/teads#Visibility(17978): The Teads AdView is visible at 0%, hidded by 1 View(s):
W/teads#Visibility(17978): - View of class io.flutter.plugin.platform.SingleViewPresentation$FakeWindowViewGroup, with id: -1, with contentDescription: null, with a size of: [width: 1050, height: 875] is hidding 100% of the ad
```
FlutterMain and the DartServiceIsolate callback list are both globals, and the
callback list state may have already been destructed when FlutterMain's
destructor runs.
Created FlutterSurrogateBinaryMessenger to make sure that channels are
holding onto engines and not viewcontrollers. This doesn't change the
public API but makes clients do what we want them to be doing, using
Engine for FlutterBinaryMessenger.
Bug: SEC-314
dding this feature all fuchsia components as a pre-flight step
as we restrict the ability for arbitrary processes to make
VMOs executable.
The Android embedder had been using a JNI call to get the observatory URI from
DartServiceIsolate. This call was not thread safe and was redundant with the
server status callback mechanism used on iOS.
When the macOS framework was initially landed, it included some iOS code
using a localized hack. This reorganizes the code structure to clearly
indicate which files are shared between iOS and macOS, vs. those that
are platform-specific.
Fixes a rare NullPointerException on Huawei devices:
```
Stacktrace:
java.lang.NullPointerException: Attempt to invoke virtual method 'android.view.DisplayAdjustments android.view.Display.getDisplayAdjustments()' on a null object reference
at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:1793)
...
```
Messages sent to the embedder host may be one-way messages with no response
handler. If the host calls FlutterEngineSendPlatformMessageResponse on a
one-way message, then just delete the message response handle.
Also update the documentation to indicate that
FlutterEngineSendPlatformMessageResponse must be called for all messages.
Previously the docs implied that some FlutterPlatformMessage objects may
have a null response_handle. The embedder will now set a response_handle for
every message (even if the sender does not expect a response).
This patch works around Android's limitations on reflection. With it embedded
platform views that use virtual node hierarchy trees should be accessible on all
Android versions to date.
The workarounds in this PR are brittle. Ideally the methods would be made public
in Android instead so we wouldn't need to employ tactics like these to work
around the missing methods.
`AccessibilityNodeInfo#getChildId` is blocked from any type of reflection
access, but the underlying private member that the getter accesses,
`mChildNodeIds`, can still be reflected on. On Android versions where we can't
access the getter, this patch falls back on reflectively accessing the field
instead. Unfortunately this field is a
[`LongArray`](https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/util/LongArray.java),
a utility data class private to Android. So in this case we're reflecting to
both access the member and actually read data from it, since we need to use
reflection to call `LongArray.get(index)`.
`AccessibilityNodeInfo#getParent()` doesn't have any lucky available underlying
members. However, `AccessibilityNodeInfo` itself is `Parcelable`, and
`mParentNodeId` is one of the pieces of data that's written to a parcel via
`AccessibilityNodeInfo#writeToParcel`. So the fallback for that is to write the
node to a parcel and then read the parcel for the ID in question. This will
break if the implementation details of `AccessibilityNodeInfo#writeToParcel`
ever change. The details have already changed enough in the past to require two
sets of logic for reading from the parcel.
The engine RunBundleAndSnapshotFromLibrary API expects a bundle path directory
containing the application's assets. If the Android embedding is using
AOT ELF library packaging and does not need to extract assets, then create an
empty directory at the bundle path.
Fixes https://github.com/flutter/flutter/issues/34287
Currently, all our host unit-tests that have rendering concerns use the software backend because of OpenGL ES availability and stability issues on the various platforms where we run host tests. Unfortunately, entire subsystems are disabled (and not tested) when rendering with the software backend. This patch pulls in SwiftShader and via pending patches in the buildroot, configures the host unit-tests to optionally use OpenGL ES in a stable manner without relying on the OpenGL drivers being present (and functional).
I have wired up the embedder test fixture in this patch to use the SwiftShader based OpenGL ES driver. I will update the shell and runtime unittests in a subsequent patch as well. The on and offscreen surfaces are configured as 1x1 pbuffer surface because we should be able to write pixel tests using OpenGL directly wihout having to deal with surfaces.
