`package` template should not create platform folders. This happen cause by default all platforms are supported and tools didn't distinguish between package and other template, which makes all platforms are true for below code,
d186792c00/packages/flutter_tools/lib/src/project.dart (L374-L380)fixes: #119844 which make #116320 makes invalid. As for why tools created deprecated `Android Embedding`, `appManifestFile` does not exist for `package` template, which make below code to trigger,
https://github.com/flutter/flutter/blob/master/packages/flutter_tools/lib/src/project.dart#L768-L770
This does not happen with `module` and `plugin` as it have specific condition check for them. I try to reproduce it with `app` template but didn't succeed
* Use correct API doc link in create --sample help message
* Verify Flutter and Dart website links in tool help messages use https
* Adjust test failure reasoning message
* Add an integration test to plugin template example
Dart unit tests don't exercise host-side plugin code at all, so the
example tests in the plugin template currently have very little
meaningful coverage. This adds an integration test to the example app
when creating a plugin, so that there's an example of how to actually
test that a complete round-trip plugin call works.
This is done as a separate template that's currently only used by the
plugin template because I don't know what a good example for a
non-plugin case would be that isn't largely just a duplicate of the
widget tests. However, the integration test pre-includes conditionals
around the parts that are plugin-specific so that it can more easily be
expanded to other use cases later (e.g., in
https://github.com/flutter/flutter/issues/68818).
Part of https://github.com/flutter/flutter/issues/82458
* Add integration test to expected dependencies of a plugin app
* Test fixes
* Make an explicit test case
The recent survey suggests that some people are not finding documentation after they get started with Flutter, so let's just give them links right away. It might not help everyone but there's not really any downside so...
* Building shared C source code as part of the native build for platforms Android, iOS, Linux desktop, MacOS desktop, and Windows desktop.
* Sample code doing a synchronous FFI call.
* Sample code doing a long running synchronous FFI call on a helper isolate.
* Use of `package:ffigen` to generate the bindings.
