* flutter analyze --watch auto detect if in flutter repo
* move isFlutterLibrary from AnalyzeOnce into AnalyzeBase for use by AnalyzeContinuously
* pass --flutter-repo to analysis server when analyzing the flutter repository
* enhance flutter analyze --watch to summarize public members lacking documentation

* pass the value of the android sdk

* swap flag

* allow the user to set the android-sdk location

On Fuchsia, the system compositor is responsible for drawing shadows
for physical model layers with non-zero elevation.

Also fixed a bug where _needsCompositing was not being cleared prior
to updating it.

Fixes https://github.com/flutter/flutter/issues/11238

See https://github.com/flutter/flutter/issues/11168

* Ensure that a frame is allways scheduled when a RenderObject marks itself as needing a semantics update

Fixes issue 2 described in https://github.com/flutter/flutter/issues/10971

Previously, an object could call `markNeedsSemanticsUpdate` and its wish would never be granted because no frame was scheduled that would actually update the semantics. This caused an issue during scrolling on Android where at the end of the scroll the `RenderIgnorePointer` would stop blocking the semantics of the scrolled view, call `markNeedsSemanticsUpdate`, but then no frame was scheduled to actually put the semantics of the scrolled view back into the semantics tree. That made the scrolled view unusable for a11y users.

At first I was a bit wary to call `requestVisualUpdate` within `markNeedsSemanticsUpdate` because technically the visual is fine, we only need the frame it schedules to update the semantics. However, it seems like we are using `requestVisualUpdate` for exactly that purpose in other places already where we just need an update to the semantics (e.g. https://github.com/flutter/flutter/blob/76a50fe0ca9641a835517ca020f9089453989011/packages/flutter/lib/src/rendering/object.dart#L2408).

* add tests

In
https://github.com/dart-lang/sdk/commit/df8bf384eb815cf38450cb50a0f4b62230fba217
a new functionality of the Dart VM Service Protocol has been introduced.

Clients connected to the Service Protocol are now able to expose
services that other clients (e.g. Observatory) can invoke through the
Service Protocol itself.

With these changes Flutter Tools register them self as a `reloadSources`
(a.k.a. HotReload) capable client.
Observatory is already listening for the clients which expose this
functionality and uses by default the service based version of
`reloadSources` when available, so requesting a HotReload from
Observatory will trigger the full Flutter HotReload.

Related https://github.com/dart-lang/sdk/issues/30023
Related https://github.com/flutter/flutter/pull/11229
Related https://github.com/flutter/flutter/pull/11256

Update --local-engine to account for changed host architecture of 32-bit Android debug builds. (#11263)

Roll engine to 03e642bc8940441bbad5c2fb7d3ca868c1fdad54.

Revert "Update --local-engine to account for changed host architecture of 32-bit Android debug builds. (#11251)" (#11259)

This reverts commit 3f514fcf.

This reverts commit 35c49897.

* Register tools as a reloadSources service

* Fix code style and comments

* Fix nits and Add documentation

* Format error message

Update --local-engine to account for changed host architecture of 32-bit Android debug builds. (#11251)

Roll engine to 7480e32854606e554ae37f8bd241c050bdc565c4.

Discovered dead code during review of #10791

* Adds a PageRouteObserver

Required for https://github.com/flutter/plugins/pull/174.
See also https://github.com/flutter/flutter/issues/11216.

* formatting fixes

* Make RouteObserver generic

Fixes https://github.com/flutter/flutter/issues/10917

* Quiet debug test runner output when in machine mode.

See: https://github.com/flutter/flutter-intellij/issues/1176

* json => machine

flutter_tools depends on cli_util, plugin, and stream_channel but hadn't
explicitly declared them as dependencies.

In some cases, we've seen interactions between Instruments and the iOS
simulator that cause hung instruments and DTServiceHub processes. If
enough instances pile up, the host machine eventually becomes
unresponsive.

Until the underlying issue is resolved, manually kill any orphaned
instances (where the parent process has died and PPID is 1) before
launching another instruments run.

It's probably too much of a foot gun.

Also, emphasize what you have to do in case people didn't read the design principles document.

* fix examples/layers/widgets/gestures.dart

* use a list of colors to avoid error prone in elseif

* address review comments

* add tests

* keep index to lower complexity

* address review comments

* Disable cocoapods stats

* Add a comment for code readers

* fix new test

* start

* with create

* refactor cocoapod code, add tests

* fix tests

* throw when cocoapod missing

* obj-c projects don’t use use_framework!

Apply a 30 second timeout to Android/iOS device polling.

If there's a device poll already in progress, skip polling for new
devices; wait for the first request to return/timeout.