* Revert "Change github readme links to be served by github (#13929)"
This reverts commit fd516d9538e23dcfebf48ddc0efd7041fe8068cd.
* Revert " Rename SemanticsFlags to SemanticsFlag (#13994)"
This reverts commit 24e3f7053671713e05ee6be29c5ba88ed8fce543.
* Revert "Make artifact downloading more robust for flaky networks (#13984)"
This reverts commit 4d37e03e1d93eb88ed47a43fe5b08a25dca86171.
* First version
* Add a clarifying comment
* Add verify to ZipDecoder.decodeBytes call
* Review comments
* Need OS Error for missing files
* FileSystemException, not OSError.
* First version
* Prevent modification of .flutter during analytics test
* Pass in directory and override analyzer warning due to conditional import
* Review comments
This broke the coverage tool, as material/animated_icons/animated_icons.dart
was loaded twice as a part, once directly animated_icons_private_test, and one
through animated_icons_private_test->flutter_tester->...->material
The coverage package assumes a 1:1 mapping between VM scripts and URIs due to a
limitation in the underlying vm_service_client package, which currently doesn't
provide a unique identifier for VM scripts.
The underlying issue is tracked by dart-lang/coverage#194.
* Send RPC request to switch assets directory on hot reload.
This is needed to pick up updated assets that are expected to be picked up on hot reload.
* Assert assets directory is not null.
* Better multiple future wait
* Add type annotation
This simply updates the package dependencies by running flutter update-packages --force-upgrade.
I'm doing this with no other changes, because the last time I tried that, redness occurred. I want to isolate the problem to a "clean" update of the packages.
It looks like the plugins device_info, connectivity, and url_launcher haven't yet had their gradle configurations updated, so they fail when trying to build with the new gradle. I did not upgrade for those three packages only (in flutter_gallery) until we are ready to fix them (fixing them for master will break them for alpha users, so we need to do an alpha roll to do that).
* Plumb a --strong option through to the front end server and the engine
so that we can run flutter apps in preview-dart-2 and strong mode
* - Address analyzer lint issues
*- correctly set up strong mode option in the case of AOT builds
This started breaking the analyzer following https://github.com/flutter/flutter/pull/13889
The test version of the material_animated_icons did not include the meta
package (needed for the @required tag) and was also not including all
the generated icons files.
Ideally we should find a way to fix this without enumerating all the
icons in the test file.
But for now just adding the missing file to fix the build breakage.
Fixes#13743Fixes#12379
Follow-up to #13745
Also adds an option to hide gestures introduced by `InkWell` and `InkResponse` from the semantics tree (see also `GestureDetector.excludeFromSemantics`).
* Revert "Revert "Enable developers to run pod from terminal directly and skip pod install if possible. (#13374)" (#13770)"
This reverts commit 0759043e47395b692bff7d6aa045c1ecb06627eb.
* some nits on cocoapods code
* put back the FLUTTER_FRAMEWORK_DIR env variable
Executables have '.exe' extension on Windows. We do have to specify extension for gen_snapshot since when running with local engine, we are looking for that exact file before launching it.
This reverts the change to `user_accounts_drawer_header.dart`
(and the associated test), as it was causing regressions in layout
of the drawer header.
https://github.com/flutter/flutter/issues/13743
* Create CupertinoScrollbar
* handle main axis margin
* Adaptive material scrollbar and tests
* Small tweaks
* reapply changes on head
* Docs
* start
* Refactored ScrollbarPainter to be more immutable
* fix tests
* fix bug: one animationcontroller pointed to multiple painters
* some docs tweak
* remove unused import
* review
* review
* add dispose
**tl;dr:** A `RenderObject` can only be an effective semantics boundary if it actually owned a `SemanticsNode` in the previous tree generation.
When using the `BlockSemantics` widget it is possible to introduce `RenderObject`s that are configured to be a semantics boundary, but because their semantics are blocked by `BlockSemantics` they will not (immediately) end up owning a `SemanticsNode`. When now a descendant of such a node-less semantics boundary marks itself as needing a semantics update we walk up the tree until we find the closest semantics boundary (which is our node-less `RenderObject`). We now incorrectly assume that this semantics boundary has a valid `SemanticsNode` and only regenerate the semantics subtree below this node. However, because the identified semantics boundary doesn't actually own a valid `SemanticsNode` asserts are throwing (e.g. `Child with id xx is invisible and should not be added to tree.`).
To fix this problem, we can just abort the walk if we reach a semantics boundary without a semantics node because (for now) we know that the semantics information of this branch will not make it into the final semantics tree.
If the semantics block is ever removed, the current algorithm re-generates the semantics for the entire branch and the semantics will be up-to-date then despite the abort. I've added a test to verify this to make sure it continues to work even when we change the algorithm.
Fixes https://github.com/flutter/flutter/issues/13326.
/cc @gavindoughtie FYI
