Fixes https://github.com/flutter/flutter/issues/101569
This block of code was originally introduced in https://github.com/flutter/engine/pull/15560 , but removing it does not have any affect on the software text editing controls in GBoard.
Before this change
* shift + arrow right/left selection would collapse after releasing the shift key.
* shift + mouse click to expand selection would collapse after releasing the shift key.
After this change
* shift key up no longer collapses the selection.
Fixes b/282290672
Google Testing currently does not support vulkan, and constructors like
this need to be behind a flag.
## 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].
- [ ] 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 Hixie said the PR is test-exempt. See [testing the engine]
for instructions on writing and running engine tests.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [x] I signed the [CLA].
- [x] All existing and new tests are passing.
Noticed this while working on https://github.com/flutter/flutter/issues/124181
In Impeller right now, Android creates a context for each surface - but in Skia, Android creates one context and shares it across surfaces. For the multiple-engine scenario this matters. This also makes it possible for Android to provide the impeller::Context independently of surface creation.
## Description
In https://github.com/flutter/engine/pull/41702, the default state of the focus bit is "false", assuming that Android will send an `onWindowFocusChanged(true)` when the window is first focused, but there appear to be some cases where that doesn't happen.
This change puts the initial state back to what it used to be: in the absence of focus change events, entering the "onResume" Android state will report the `resumed` state in Flutter. Before this PR, and after https://github.com/flutter/engine/pull/41702, if no focus events were received, it would default to `inactive`.
## Tests
- Updated tests to match.
Fixes https://github.com/flutter/flutter/issues/123307 - for Android, iOS, and Web, for the main display only (https://github.com/flutter/flutter/issues/125938 tracks supporting multiple displays, https://github.com/flutter/flutter/issues/125939 for desktop).
Desktop will need to be implemented for this, but given priority for a couple of our customers targetting foldable devices on Android I'm inclined to get this in before desktop can be finished.
The main concern for this right now is that on some Android foldable devices, setting a preferred orientation will cause letterboxing and the `MediaQuery` will _never_ get the full screen size when unfolded. This causes apps to think the screen is smaller than it is, as they've mainly been using `MediaQueryData.size` to figure this out. Android's recommendation is to not set a preferred orientation, and if you must to use the new method introduced in `ViewUtil.java` to calculate the maximal window size.
## Description
This reverts commit e49577708d9d5315fa6c001d7dc20ee80d04cd35 to re-land #41094 because the Google test failures have been fixed. There are no changes to the original PR, since the fixes were in the Google code.
Typically the AndroidShellHolder's apk_asset_provider_ is set by AndroidShellHolder::Launch when the DartExecutor runs the engine's entrypoint.
But if the engine was started by Spawn, then the apk_asset_provider_ was not being set. This would cause a crash if the resulting engine was later used to spawn another engine.
Fixes https://github.com/flutter/flutter/issues/122364
## Description
This incorporates additional signal from `Activity.onWindowFocusChanged` to help decide if the application is `resumed` or `inactive`.
When the user pulls down the notification shade or opens the app switcher in iOS, then iOS sends a notification to the application that it no longer has input focus (is no longer "active" in Apple terminology).
However, Android (at least on a Pixel) doesn't send `onPause` and `onResume` events for these things, as one might expect. Instead, this PR changes things so that we listen to `Activity.onWindowFocusChanged` and see if any of the windows still have focus.
If it doesn't have focus, then the lifecycle switches to `inactive` (even if `onPause` hasn't been called), and if it does have focus (and `onResume` hasn't been called) then we should go to `resumed`.
State changes are determined and deduped in the `LifecycleChannel` class.
Here's the old state table:
| Android State | Flutter state |
| ------------- | ------------- |
| Resumed | resumed |
| Paused | inactive |
| Stopped | paused |
| Detached | detached |
Here's the new state table:
| Android State | Window focused | Flutter state |
| ------------- | ------------- | ------------- |
| Resumed | true | resumed |
| Resumed | false | _inactive_ * |
| Paused | true | inactive |
| Paused | false | inactive |
| Stopped | true | paused |
| Stopped | false | paused |
| Detached | true | detached |
| Detached | false | detached |
* = This is the relevant change in this PR.
("Window focused" means one or more windows managed by Flutter are focused)
The `inactive` state is for when the application is running and visible, but doesn't have the input focus. An example where this currently happens are when a phone call is in progress on top of the app, or on some OEMs when going into the app switcher (I've tested on Realme and it does that, at least). With the PR, it will also go into `inactive` when the app has lost input focus, but is still in the Android `onResume` state. This means that on phones that don't pause the app when they go into the app switcher or the notification window shade (Pixel, others), the app will go into `inactive` when it didn't before. If developers weren't doing anything special in the `inactive` state before, then this PR will have no change for them. If they were, they will go into that state more often (but more consistently across OEMs).
## Related Issues
- Fixes https://github.com/flutter/flutter/issues/124591
## Tests
- Added unit tests for handling `onWindowFocusChanged`.
Issue fixed by this PR: https://github.com/flutter/flutter/issues/110138
This PR fixes an issue which is causing app crash when User tries to navigate to a new instance **FlutterFragment** (whose old instance is already present in the fragment backstack) in an Activity (which was restored to saved state after being killed in background due to memory pressure).
Detailed case to reproduce the crash and identify its' root cause:
Setup: Let's say we've an Activity1 which has a bottom nav bar with 3 tabs. Each of this 3 tabs are **FlutterFragment** i.e. Fragment1, Fragment2 & Fragment3 and all of them are using separate **FlutterEngine** but all of them will be cached. e.g. Multiple instances of **Fragment1** will be going to use same cached **FlutterEngine1**.
1. When User opens the app, Fragment1 gets added to fragment backstack
2. Then User navigates to Fragment2 (gets added to backstack as well)
3. Then User navigates to Fragment3 (gets added to backstack as well)
4. Then User puts the app in background. Due to memory pressure OS/platform kills the Activity1 and all 3 FlutterFragments while the app is in background.
5. Then after sometime User tries to bring the app to foreground from the app stack. Since Activity1 was killed by the OS/platform the app process will try to restore the Activity1 in the same state it was before it got killed. This leads to all 3 fragments present in backstack to get instantiated and then the **onAttach()** gets called for all 3, but only Fragment3 gets **onCreateView()** lifecycle event as it was the top most visible Fragment before the FragmentManager saved the state and app went into background. All 3 FlutterFragment goes through following function calls.
FlutterFragment.onAttach() -> FlutterActivityAndFragmentDelegate.onAttach(). There is a one-to-one mapping between **FlutterFragment <-> FlutterActivityAndFragmentDelegate**
<img width="977" alt="1" src="https://user-images.githubusercontent.com/8373036/231222642-1596c77c-d127-476b-9bce-8ad2e9cd3639.png">
FlutterActivityAndFragmentDelegate.onAttach() -> FlutterEngineConnectionRegistry.attachToActivity(). There is a one-to-one mapping between **FlutterEngine <-> FlutterEngineConnectionRegistry**. _**NOTE**: THIS IS VERY IMPORTANT POINT TO KEEP IN MIND TO UNDERSTAND THE ROOT CAAUSE OF THIS CRASH._
<img width="962" alt="2" src="https://user-images.githubusercontent.com/8373036/231222672-016ee708-c310-49c8-8016-070b6057af7b.png">
Since all the 3 **FlutterFragment** were just instantiated on activity restore **exclusiveActivity** will be null and exclusiveActivity will be assigned the host **FlutterActivityAndFragmentDelegate**.
<img width="880" alt="3" src="https://user-images.githubusercontent.com/8373036/231241491-c47f5aa6-96e9-4c1f-b92e-7cfed67381e2.png">
6. Then FlutterFragment.onCreateView() will be called only for Fragment3 and it will be visible without an issue as its' state gets restored properly.
7. Then if User tries to navigate to Fragment2 via instantiating new instance of it (this means that now there will be two instances of Fragment2 in the backstack), then there will be crash as it'll go through following function calls.
FlutterFragment.onAttach() -> FlutterActivityAndFragmentDelegate.onAttach().
<img width="977" alt="1" src="https://user-images.githubusercontent.com/8373036/231222642-1596c77c-d127-476b-9bce-8ad2e9cd3639.png">
FlutterActivityAndFragmentDelegate.onAttach() -> FlutterEngineConnectionRegistry.attachToActivity().
<img width="962" alt="2" src="https://user-images.githubusercontent.com/8373036/231222672-016ee708-c310-49c8-8016-070b6057af7b.png">
THIS IS WHERE THE CRASH STARTS. Since this is the second instance of Fragment2 and both instances are going to use the same cached **FlutterEngine** and hence same **FlutterEngineConnectionRegistry**, this time around **exclusiveActivity** will be non-null as it was assigned during step 5. And since exclusiveActivity will be be non null it'll try to detach from the old **ExclusiveAppComponent** via calling **exclusiveActivity.detachFromFlutterEngine()**.
<img width="878" alt="7" src="https://user-images.githubusercontent.com/8373036/231241550-09908108-1747-4ec3-bc70-145446b86eae.png">
FlutterActivityAndFragmentDelegate.detachFromFlutterEngine() -> FlutterFragment.detachFromFlutterEngine()
<img width="905" alt="4" src="https://user-images.githubusercontent.com/8373036/231222702-5ee739f2-fd71-4e20-807d-e3786e6f27fc.png">
FlutterFragment.detachFromFlutterEngine() -> FlutterActivityAndFragmentDelegate.onDestroyView(). This ideally should not be called if the hosts' **FlutterFragments.onCreateView()** was not called in the first place. Also since the previous author has added **// Redundant calls are ok.** comment, I'm guessing that this is just a fallback cleanup.
<img width="902" alt="5" src="https://user-images.githubusercontent.com/8373036/231222719-2ea28157-bd62-45fe-89ef-dd41ee7b3cca.png">
THIS IS WHERE THE CRASH HAPPENS. FlutterActivityAndFragmentDelegate.onDestroyView() -> FlutterView.detachFromFlutterEngine(). Since the lifecycle of older instance of this FlutterFragment2 was capped at onAttach(), it's **FlutterView** property will be null and calling FlutterView.detachFromFlutterEngine() will throw NPE.
<img width="902" alt="6" src="https://user-images.githubusercontent.com/8373036/231222735-55b63911-6a2d-4967-8043-298f4d413f2a.png">
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Reverts flutter/engine#40746
Googler bug: b/278174021
Failing on
```
shell/platform/android/io/flutter/plugin/editing/TextInputPlugin.java:239: Error: This method should only be accessed from tests or within private scope [VisibleForTests]
imeSyncCallback.remove();
```
This PR makes view ID signed from unsigned int64.
Initially, I made view IDs unsigned because they were opaque anyway. As
I'm working deeper into multiview, I found some issues that made me
think signed is better:
* Unsigned integers are worse
* Sometimes you want negative values to represent special values.
* Unsigned integers are dangerous (if compared with signed ones by
mistake.)
* Unsigned integers are not needed
* We're very unlikely to reach that big anyway.
* Almost all other languages support only signed integers.
* Also JavaScript only supports up to 51 bits of integer.
Therefore I think it's better to change them to signed int64, especially
before these APIs are widely used by developers.
## Pre-launch Checklist
- [ ] 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] and the [C++,
Objective-C, Java style guides].
- [ ] 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 Hixie said 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 `///`).
- [ ] I signed the [CLA].
- [ ] All existing and new tests are passing.
If you need help, consider asking for advice on the #hackers-new channel
on [Discord].
<!-- Links -->
[Contributor Guide]:
https://github.com/flutter/flutter/wiki/Tree-hygiene#overview
[Tree Hygiene]: https://github.com/flutter/flutter/wiki/Tree-hygiene
[Flutter Style Guide]:
https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo
[C++, Objective-C, Java style guides]:
https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
[testing the engine]:
https://github.com/flutter/flutter/wiki/Testing-the-engine
[CLA]: https://cla.developers.google.com/
[flutter/tests]: https://github.com/flutter/tests
[breaking change policy]:
https://github.com/flutter/flutter/wiki/Tree-hygiene#handling-breaking-changes
[Discord]: https://github.com/flutter/flutter/wiki/Chat
* Fix mip-map generation in unit-tests where the command buffer was not
submitted.
* Cleanup descriptor counts being always 1 in Vulkan code-gen.
* Reworked capabilities. Platforms can add to the base capability set.
* Vulkan backend picks between more available color and stencil formats.
* Descriptor pools are dynamically sized.
* Layout transitions are more explicit. Both allocated and swapchain images
track their own layouts and redundant transitions are avoided.
* Objects active in a pending command buffer are collected but the waits happen
on a separate fence waiter. Thread is named
"io.flutter.impeller.fence_waiter".
* Added queue and command buffer instant markers for better traces.
* Command pools and their buffers are now thread local. Fixes sync validation
failure.
* Debug reports are now more readable and command buffer and queue breadcrumbs
will be displayed on a validation report.
* Staging buffers are back.
* Pipeline caches have been wired up. After 50 frames, the current Vulkan
pipeline cache will be written out to disk for subsequent launches. Writes
will happen on a background worker.
* Runtime stages have been wired up. But the build rules to provide the right
stages are still remaining.
Fixes https://github.com/flutter/flutter/issues/121536
Fixes https://github.com/flutter/flutter/issues/121627
Fixes https://github.com/flutter/flutter/issues/121632
Fixes https://github.com/flutter/flutter/issues/120499
inputs = [ "android_exports.lst" ]
was missing from the flutter_shell_native rule, which meant if you edited android_exports.lst it would not notice and would not rebuild/relink.
Kaushik already did most of the great work. This patch gets us to a point where
all the playgrounds tests pass and the common performance optimizations are in
place. All known non-compute Impeller features should be implemented. There are
iOS only performance optimizations that haven’t been opted into because these
are behind define guards. These need to be generalized. Without that, the
performance of this backend will lag behind that of the Metal backend but only
because it is not an apples to apples comparison.
The general rubric was to keep the code and concepts as similar to the Metal
backend as possible.
The list of updates, all to the Vulkan Impeller backend:
* MSAA is wired up.
* Depth and stencil attachments and pipeline states are wired up.
* Got rid of Vulkan specific hacks in the inline pass context that were
preventing clips from working.
* Storage modes for both device buffer and texture allocation are respected.
This includes optimal usage of tile memory for device transient attachments.
* Host coherent memory for textures is no longer a requirement with explicit
mapping management and write flushes.
* Texture uploads should be optimized for the UMA case without needing a staging
buffer. That entire pipeline has been reworked.
* Textures track their current layout and ensure they get to the right layout
based on usage without redundant transitions.
* Cube textures are now supported.
* Mipmapping has been reworked to correct image layout errors. With the new
texture layout transition management, blit passes should be a whole lot easier
to read and reason about.
* Allocator allocations are named using Vulkan debug utilities and the allocator
(VMA). Comes in handy when chasing leaks. All of which are chased down.
* Left some handy utilities in there to debug resource leaks after context
shutdown. These are validation errors.
* Debug groups are pushed around render pass command encoding as well as the
entire pass contents. This mimics the behavior of the Metal backend and it
should be easy to map traces using both backends in Xcode and RenderDoc.
* Command buffer submission allows for tracking the life cycles of all resources
referenced in the command stream and ensuring that the objects stay alive till
past the submission of the command buffer. All use-after-free issues due to
this class of issue have been chased down.
* Command pools are now context global instead of being created per pass.
* Descriptor pool are now context global instead of being created per pass.
Individual descriptor types are now reference counted and returned to the pool
when not needed. The pool is still fixed size though (and hence relatively
large).
* All instances of global waitIdle on the device are removed during normal
operation. The only times a waitIdle may happen is during swapchain recreation
and context destruction.
* Swapchain adapt to them going out of date with the underlying surface and
seamlessly resize as necessary on the next drawable acquisition.
* Playgrounds are resizable.
* Pipeline front face and cull modes are respected.
* Clears for all attachments are respected.
* Maximum textures sizes supported on the device are respected instead of
hardcoding the minimum Vulkan requirement.
Fixes https://github.com/flutter/flutter/issues/112388
Fixes https://github.com/flutter/flutter/issues/112648
Fixes https://github.com/flutter/flutter/issues/112647 and a few other issues...
* working commit
* some clean up
* white space fixes
* whitespace
* remove unused import
* Addressing PR comment, fix tests, update touch packet on Andriod
* formatting n whitespace again
* add new field to web ui pointer.dart
* update test
* whitespace
* fix test
* PR comments
* fix test
* whitespace
* fix test by factoring out logic into helper function
* whitespace
* fix malformed string
* pr comments
* fix type issue
* sigh whitespace
* revert test changes :)
* pr comments + separate out tests
* extra space
* change test name
* Implemented wide gamut images for iOS
Moved the surface to an extended range color format.
* wrong gamma but default pixel format set to bgra10_xr
* BGR10_XR add
* format
* updated todos
* updated todo with information about pixel formats
* switched logic for determining if we have a wide gamut image
* cleaned up gamut math to match style and linked source
* made the color attachment pixel format match the surface
* updated vulkan format switch
* removed comment
* added enable disable switch
* moved default to bgr10 for now since there is a bug where someone is still reading this, msaa?
* fixed the decoder settings to make sure we don't lose wide gamut colors
* fixed stored srgb gamut variable
* fixed false lint
* updated test
* added ability to grab the surface data for tests
* made the screenshot utility return the format
* added width and height to the platform channel payload
* fixed a couple of broken targets
* moved back the default pixel buffer format
* cleanup and add docstrings
* made the surfacedata feature only available in debug builds
* added decoding unit test
* fixed objc tests
* turned off by default
* bdero feedback1
* bdero2
* bdero3
* fixed merge issue
* removed using std::shared_ptr
