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
The difference between this PR and the original is the change to the `AndroidManifest.xml`. For context, right before the original PR landed, [a change to upgrade the target sdk](https://github.com/flutter/engine/pull/47683) in the manifest from 31 to 33 landed. It also removed the lint complaining about using an old target sdk version from the baseline lint file. So this change upgrading the sdk, but not the target sdk in the manifest, triggered the lint again.
For the rest of the PR, [see the description of the original PR](https://github.com/flutter/engine/pull/47609).
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Reverts flutter/engine#47609
Initiated by: zanderso
This change reverts the following previous change:
Original Description:
~**This should not land until https://github.com/flutter/buildroot/pull/790 (re)lands, and I swap the buildroot url back to the latest commit.**~ ~Reland of PR to update buildroot at https://github.com/flutter/buildroot/pull/792. ~ <- landed, and changed the buildroot commit to the latest in DEPS
Upgrades to android api 34
Also:
1. Upgrades to java 17 in DEPS/ci, because the linter now requires it.
2. Stops running some roboelectric tests on android apis 16-18, because Roboelectric indicated those versions were unsupported and we don't support them either.
3. Applies the four trivial new suggestions from the newer linter.
4. Updates the baseline lint to include the new non-trivial lint ([fixed in a different PR](https://github.com/flutter/engine/pull/47817/files)).
5. Changes some instances where we were hardcoding android apis as numbers (e.g. `sdk = 16') to use version codes (see the [comment below](https://github.com/flutter/engine/pull/47609#issuecomment-1800308658)).
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
As part of eliminating the Flutter buildroot
(https://github.com/flutter/flutter/issues/67373), we are moving all
third-party dependencies from //third_party to //flutter/third_party.
Once all third-party dependencies have been migrated, tooling and config
will be moved and the buildroot will be eliminated altogether.
No tests changed because there is no semantic change to this PR. This is
simply relocating a dependency.
This makes sure the frame timings recorder and vsync waiter implementations get
the correct refresh rate if or when it adjusts at runtime. This should be OK
because we'll only query the refresh rate when the display metrics actually
change, which is much less frequent than every frame. I experimented with an NDK
implementation in the previous patch, but that vastly restricts the API levels
we can support, and currently on API 30 and 31 it just calls Java methods
through JNI anyway.
I've refactored the way Display updates are reported so that AndroidDisplay can
just dynamically get the refresh rate correctly. These values are used by a
service protocol extension and by some Stopwatches on the CompositorContext.
See also #29765Fixesflutter/flutter#93688Fixesflutter/flutter#93698
* Add new channel updateEditingStateWithDelta
* Fix formatting
* Fix formatting
* Fix formatting
* Add equality case
* formatting
* Implement TextEditingDelta class to encapsulate delta logic
* Formatting
* Also send new composing/selection along with delta
* Utilize an ArrayList of TextEditingDeltas to take into account batch editing
* clear batch deltas when editing state is updated by framework, we don't want to collect deltas from the framework because they have already been applied to the value on the framework side
* fix formatting
* formatting
* formatting
* Add enableDeltaModel flag to choose between updateEditingValue and updateEditingValueWithDeltas
* Add autofill support for delta model
* formatting
* update
* Fix issues with composing region
* formatting
* Remove
* Fix out of bounds error when textfield is initialized with text
* Clean up logs
* formatting
* update licenses
* Fix deletion issues
* formatting
* delta -> deltaType
* updates
* formatting
* formatting
* Fix logs
* Add tests for TextEditingDelta
* formatting fixes
* remove unused imports
* Fix return type for getDeltaType
* Fix tests
* Fix ListenableEditingStateTest
* formatting
* Fix typo
* Add test for deltas when setComposingText
* formatting
* Updates to test
* fix typo
* formatting
* Verify all properties of delta for test
* formatting
* Add VisibleForTesting import
* fix test
* fix formatting
* fix tests
* fix tests
* fix tests
* updates for tests
* remove ide made file
* Fix more tests
* Fix TextEditingDelta tests
* Add test for verifying delta is generated on setComposingText
* Add TextInputPlugin tests for replacement and deletion deltas
* formatting
* formatting
* Capture delta on setSpan and clear deltas when generated from the framework and when we skip updating the framework
* fix formatting
* update tests to reflect new clear batch delta calls
* Make deletion inline with platform
* fix tests
* Address reviewer comments
* formatting
* fix tests
* fix tests
* move delta inference to framework
* update tests
* formatting
* fix tests
* Formatting
* get -> extract
* More tests and address reviewer comments
* clean up logs
* Address reviewer comments
* formatting
* formatting
* Remove testing constructor
* send as deltas