mirror of
https://github.com/flutter/flutter.git
synced 2025-06-03 00:51:18 +00:00
[wiki migration] Leftover wiki pages and links (#148989)
This is waiting on - https://github.com/flutter/flutter/pull/148777 - https://github.com/flutter/flutter/pull/148790 After this PR lands, there will likely be 1-2 more clean up PRs, after which the migration will be done! --- This moves the remaining wiki pages as planned in [flutter.dev/go/migrate-flutter-wiki-spreadsheet](https://docs.google.com/spreadsheets/d/1x65189ZBdNiLRygpUYoU08pwvXD4M-Z157c6pm8deGI/edit?usp=sharing) It also adds the team labels to the label bot for future PRs. Changes to the content were only updating cross links, or links to refer to the main branch rather than master. Remaining links to the wiki will be updated once all other pages have finished moving, they still work in the meantime. Part of https://github.com/flutter/flutter/issues/145009
This commit is contained in:
parent
a1a33e63b9
commit
1fbcbb73a0
@ -1240,10 +1240,7 @@ Future<void> verifyIssueLinks(String workingDirectory) async {
|
||||
final Set<String> suggestions = <String>{};
|
||||
final List<File> files = await _gitFiles(workingDirectory);
|
||||
for (final File file in files) {
|
||||
if (path.basename(file.path).endsWith('_test.dart')
|
||||
|| path.basename(file.path) == 'analyze.dart'
|
||||
// TODO(Piinks): Disables checks in docs/unsorted, enabling unchanged initial migration, https://github.com/flutter/flutter/issues/145009
|
||||
|| file.path.contains('unsorted_wiki')) {
|
||||
if (path.basename(file.path).endsWith('_test.dart') || path.basename(file.path) == 'analyze.dart') {
|
||||
continue; // Skip tests, they're not public-facing.
|
||||
}
|
||||
final Uint8List bytes = file.readAsBytesSync();
|
||||
@ -1330,10 +1327,6 @@ Future<void> verifyRepositoryLinks(String workingDirectory) async {
|
||||
final Set<String> suggestions = <String>{};
|
||||
final List<File> files = await _allFiles(workingDirectory, null, minimumMatches: 10).toList();
|
||||
for (final File file in files) {
|
||||
// TODO(Piinks): Disables checks in docs/unsorted, enabling unchanged initial migration, https://github.com/flutter/flutter/issues/145009
|
||||
if (file.path.contains('unsorted_wiki')) {
|
||||
continue;
|
||||
}
|
||||
final Uint8List bytes = file.readAsBytesSync();
|
||||
// We allow invalid UTF-8 here so that binaries don't trip us up.
|
||||
// There's a separate test in this file that verifies that all text
|
||||
|
@ -22,7 +22,7 @@ Flutter provides multiple functionality through self-service services. Most of t
|
||||
<tr>
|
||||
<td>Flutter organization members
|
||||
</td>
|
||||
<td><a href="https://github.com/flutter/flutter/wiki/Contributor-access">Anyone with write access to the flutter organization resources</a>.
|
||||
<td>[Anyone with write access to the flutter organization resources.](./contributing/Contributor-access.md)
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
@ -66,7 +66,7 @@ Flutter provides multiple functionality through self-service services. Most of t
|
||||
</td>
|
||||
<td><a href="https://github.com/flutter/cocoon/blob/main/CI_YAML.md">Link</a>
|
||||
</td>
|
||||
<td>Top level folder of the GitHub repositories. E.g. <a href="https://github.com/flutter/flutter/blob/master/.ci.yaml">flutter/flutter</a>.
|
||||
<td>Top level folder of the GitHub repositories. E.g. <a href="https://github.com/flutter/flutter/blob/main/.ci.yaml">flutter/flutter</a>.
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
@ -100,7 +100,7 @@ Flutter provides multiple functionality through self-service services. Most of t
|
||||
</td>
|
||||
<td>Flutter contributors
|
||||
</td>
|
||||
<td><a href="https://github.com/flutter/flutter/wiki/flutter-firebaselab-tests">Link</a>
|
||||
<td>[Link](./infra/Flutter-FirebaseLab-Tests.md)
|
||||
</td>
|
||||
<td>These configurations go directly in the .ci.yaml file of <a href="https://github.com/flutter/flutter">flutter/flutter</a> repository.
|
||||
</td>
|
||||
@ -112,7 +112,7 @@ Flutter provides multiple functionality through self-service services. Most of t
|
||||
</td>
|
||||
<td>Flutter contributors
|
||||
</td>
|
||||
<td><a href="https://github.com/flutter/flutter/wiki/code-signing-metadata">Link</a>
|
||||
<td>[Link](./engine/release/Code-signing-metadata.md)
|
||||
</td>
|
||||
<td>GN files and global generator scripts in the <a href="https://github.com/flutter/engine">flutter/engine</a> repository.
|
||||
</td>
|
||||
@ -124,7 +124,7 @@ Flutter provides multiple functionality through self-service services. Most of t
|
||||
</td>
|
||||
<td>Flutter contributors
|
||||
</td>
|
||||
<td><a href="https://github.com/flutter/flutter/wiki/Testing-Android-Changes-in-the-Devicelab-on-an-Emulator">Link</a>
|
||||
<td>[Link](./platforms/android/Testing-Android-Changes-in-the-Devicelab-on-an-Emulator.md)
|
||||
</td>
|
||||
<td>Flutter Github Wiki page under the “Android Development” Section.
|
||||
</td>
|
@ -1,6 +1,6 @@
|
||||
## If flutter.dev is down
|
||||
|
||||
If one of our web sites is down, please ping `@emergency` on our [[Discord server|Chat]].
|
||||
If one of our web sites is down, please ping `@emergency` on our [Discord server](./contributing/Chat.md).
|
||||
|
||||
## If you find a security vulnerability
|
||||
|
36
docs/README.md
Normal file
36
docs/README.md
Normal file
@ -0,0 +1,36 @@
|
||||
This wiki is primarily aimed at engineers building or making contributions to Flutter.
|
||||
|
||||
If you are new to Flutter, then you will find more general information on the Flutter project, including tutorials and samples, on our Web site at [flutter.dev](https://flutter.dev). For specific information about Flutter's APIs, consider our API reference which can be found at the [api.flutter.dev](https://api.flutter.dev/).
|
||||
|
||||
If you want to know what we're likely to do in the future, our [roadmap](./roadmap/Roadmap.md) may be of interest.
|
||||
|
||||
If you intend to contribute to Flutter, welcome! You are encouraged to start with [our contributor guide](../CONTRIBUTING.md), which helps onboard new team members. It points to the most relevant pages on this wiki. You are also invited to join our [Discord](./contributing/Chat.md) server.
|
||||
|
||||
|
||||
## Index of notable sections
|
||||
|
||||
* [Actionable bugs](./triage/README.md#what-makes-an-issue-actionable), and the closing of unactionable bugs
|
||||
* [Breaking changes](./contributing/Tree-hygiene.md#handling-breaking-changes)
|
||||
* [Cherrypick process](./releases/Flutter-Cherrypick-Process.md)
|
||||
* [Closing issues](./contributing/issue_hygiene/README.md#closing-issues)
|
||||
* [Dashboards](./infra/Dashboards.md)
|
||||
* [Debugging a broken engine autoroll](./engine/Debugging-the-engine.md#bisecting-a-roll-failure)
|
||||
* [Deprecations](./contributing/Tree-hygiene.md#deprecations)
|
||||
* [Design documents](./contributing/Design-Documents.md)
|
||||
* [Discord](./contributing/Chat.md)
|
||||
* [Engineering Philosophy](./contributing/Style-guide-for-Flutter-repo.md#philosophy)
|
||||
* [Flaky tests](./contributing/issue_hygiene/README.md#flaky-tests)
|
||||
* [flutter.dev is down](./In-case-of-emergency.md)
|
||||
* [Issue prioritization](./contributing/issue_hygiene/README.md#priorities)
|
||||
* [Labels](./contributing/issue_hygiene/README.md#labels)
|
||||
* [Milestones](./contributing/issue_hygiene/README.md#milestones)
|
||||
* [Plugin compatibility policy](./contributing/Style-guide-for-Flutter-repo.md#plugin-compatibility)
|
||||
* [Reviewing code](./contributing/Tree-hygiene.md#getting-a-code-review)
|
||||
* [RFC process](./contributing/issue_hygiene/README.md#how-to-propose-a-specific-change)
|
||||
* [Status of popular issues](./contributing/issue_hygiene/Popular-issues.md)
|
||||
* [Submitting code, process for](./contributing/Tree-hygiene.md#overview)
|
||||
* [Support levels, definitions of](./about/Values.md#support)
|
||||
* [Symbolicating stack traces](./engine/Crashes.md)
|
||||
* [Threading in the Engine](./about/The-Engine-architecture.md#threading)
|
||||
* [When will my bug be fixed?](./contributing/issue_hygiene/README.md#when-will-my-bug-be-fixed)
|
||||
* [Security best practices](./infra/Security.md#best-practices)
|
@ -26,7 +26,7 @@ Here are some terms that we use in the Flutter project and what they mean:
|
||||
|
||||
- **Modular application delivery**. The ability to package a single app into multiple separate archives when compiling it, and download them independently as needed.
|
||||
|
||||
- **NTE**. "Needs-Tests Exemption". Indicates that a PR does not need tests, typically because the PR is refactoring code without changing the semantics of the code, or because it actually does have tests but the automated systems didn't recognize them. A test exemption consists of a comment on the PR that has a line that starts with the string `test-exempt: ` followed by an explanation of why, from someone who is allowed to give test exemptions. A bot will add a comment to a PR if a test exemption is required. See [Tree Hygiene](https://github.com/flutter/flutter/wiki/Tree-hygiene) for instructions on getting test exemptions.
|
||||
- **NTE**. "Needs-Tests Exemption". Indicates that a PR does not need tests, typically because the PR is refactoring code without changing the semantics of the code, or because it actually does have tests but the automated systems didn't recognize them. A test exemption consists of a comment on the PR that has a line that starts with the string `test-exempt: ` followed by an explanation of why, from someone who is allowed to give test exemptions. A bot will add a comment to a PR if a test exemption is required. See [Tree Hygiene](../contributing/Tree-hygiene.md) for instructions on getting test exemptions.
|
||||
|
||||
- **Out-of-band (OOB) failure**. A test failure in our CI that is caused by some change external to the repository, not the failing commit (or flake). For instance, an infrastructure change or a change to an external server used by tests could cause an out-of-band failure. In general, CI should minimize the possibility of out-of-band failures by being as hermetic as possible.
|
||||
|
||||
|
@ -30,14 +30,14 @@ The Flutter project has many teams, including, but not limited to:
|
||||
|
||||
There are also specific cross-cutting areas of work that may have their own subteam and that affect multiple subteams (e.g. accessibility, performance, etc).
|
||||
|
||||
We also work closely with other projects, such as [Dart](https://dart.dev) and [Skia](https://skia.org), and with many [customers](https://github.com/flutter/flutter/wiki/Issue-hygiene#customers).
|
||||
We also work closely with other projects, such as [Dart](https://dart.dev) and [Skia](https://skia.org), and with many [customers](../contributing/issue_hygiene/README.md#customers).
|
||||
|
||||
## Responsibilities
|
||||
|
||||
Subteams are responsible for reviewing PRs in their area, triaging issues, and scheduling work.
|
||||
How subteams organize themselves is not defined by this document. This document does not attempt to impose a process, merely a set of responsibilities.
|
||||
|
||||
See the [Roadmap](https://github.com/flutter/flutter/wiki/Roadmap) and [What should I work on?](https://github.com/flutter/flutter/wiki/What-should-I-work-on%3F) pages for details on how to prioritize work.
|
||||
See the [Roadmap](../roadmap/Roadmap.md) and [What should I work on?](../contributing/What-should-I-work-on.md) pages for details on how to prioritize work.
|
||||
|
||||
### Reviewing PRs
|
||||
|
||||
@ -47,7 +47,7 @@ Please review PRs in your area (based on label and/or repositories). The goal is
|
||||
|
||||
Please triage issues with your label on a regular basis. You may do this in whatever manner you prefer (on your phone while in line for lunch, as a team exercise in a dedicated meeting room, by having some sort of team rotation, whatever).
|
||||
|
||||
You must cover these bug lists in particular: https://github.com/flutter/flutter/wiki/Triage#area-focused-triage
|
||||
[You must cover these bug lists in particular.](../triage/README.md#triage-process-for-teams)
|
||||
|
||||
* Assign bugs that you are working on or that you have committed to work on.
|
||||
|
||||
@ -55,9 +55,9 @@ You must cover these bug lists in particular: https://github.com/flutter/flutter
|
||||
|
||||
* Make sure that assigned bugs have a month-based milestone (see section below).
|
||||
|
||||
See our page on managing issues: https://github.com/flutter/flutter/wiki/Issue-hygiene
|
||||
[See our page on managing issues.](../contributing/issue_hygiene/README.md)
|
||||
|
||||
Keep an eye out for bugs that should block releases, update the bad builds page accordingly: https://github.com/flutter/flutter/wiki/Bad-Builds
|
||||
Keep an eye out for bugs that should block releases, update the [bad builds](../releases/Bad-Builds.md) page accordingly.
|
||||
|
||||
### Be conservative when scheduling
|
||||
|
||||
|
@ -45,7 +45,7 @@ We may sometimes gate features behind flags until we are confident of their qual
|
||||
|
||||
## 🤣 Have fun doing it
|
||||
|
||||
Last, but definitely not least, we want to make sure that our work environment is pleasant for everyone involved. Your health and the health of your family and friends is more important than Flutter. Our community [is welcoming](https://github.com/flutter/flutter/blob/main/CODE_OF_CONDUCT.md). We don't know everything; all of us can make mistakes.
|
||||
Last, but definitely not least, we want to make sure that our work environment is pleasant for everyone involved. Your health and the health of your family and friends is more important than Flutter. Our community [is welcoming](../../CODE_OF_CONDUCT.md). We don't know everything; all of us can make mistakes.
|
||||
|
||||
We want team members to feel empowered to make changes to the code and to our processes.
|
||||
|
||||
@ -70,7 +70,7 @@ The list of supported platforms on flutter.dev is describing the platforms suppo
|
||||
|
||||
For each area, we consider the level to which we provide support:
|
||||
|
||||
0. We will literally help you with your code if things don't work. This is very rare. (See also "[top-tier customers](https://github.com/flutter/flutter/wiki/Issue-hygiene#customers)".)
|
||||
0. We will literally help you with your code if things don't work. This is very rare. (See also "[top-tier customers](../contributing/issue_hygiene/README.md#customers)".)
|
||||
|
||||
1. We will make a best effort to ensure that well written code works (e.g. we have testing on that platform). This is a common level for target platforms that have reached a label of "stable" (e.g. Android, iOS) on devices that are widely available (e.g. 64bit ARM). This corresponds to the "Supported Google-tested platforms" category on the list of supported platforms.
|
||||
|
||||
@ -89,7 +89,7 @@ For each area, we consider the level to which we provide support:
|
||||
|
||||
_See also:_
|
||||
|
||||
* [Code of Conduct](https://github.com/flutter/flutter/blob/main/CODE_OF_CONDUCT.md)
|
||||
* [Contributor Guide](https://github.com/flutter/flutter/blob/main/CONTRIBUTING.md)
|
||||
* [Code of Conduct](../../CODE_OF_CONDUCT.md)
|
||||
* [Contributor Guide](../../CONTRIBUTING.md)
|
||||
* [Flutter's Culture of Inclusivity](https://flutter.dev/culture)
|
||||
* [Flutter culture and how to preserve it](https://medium.com/flutter/flutter-culture-and-how-to-preserve-it-436b4ed1031d)
|
@ -4,12 +4,12 @@ We grant commit access (which includes full rights to the issue database, such a
|
||||
|
||||
Specifically, if you meet one of the following criteria and you have a sponsor (someone who already has contributor access and agrees that you should be granted access), then please ask your sponsor to propose, on the #server-support [Chat](Chat.md) channel, that you be made a member of the team, and then reply to that message explaining which criteria below you are claiming to meet. The possible criteria are:
|
||||
|
||||
* You have a long history of participating productively, e.g. in our [Chat](Chat.md) channels, helping with [Triage](https://github.com/flutter/flutter/wiki/Triage), helping other contributors track down problems, finding meaningful issues in submitted PRs, helping people in our #help channel, etc, all while demonstrating exemplary behavior that closely aligns with our [code of conduct](https://github.com/flutter/flutter/blob/main/CODE_OF_CONDUCT.md).
|
||||
* You have a long history of participating productively, e.g. in our [Chat](Chat.md) channels, helping with [Triage](../triage/README.md), helping other contributors track down problems, finding meaningful issues in submitted PRs, helping people in our #help channel, etc, all while demonstrating exemplary behavior that closely aligns with our [code of conduct](https://github.com/flutter/flutter/blob/main/CODE_OF_CONDUCT.md).
|
||||
* You have recently submitted several PRs that have landed successfully (received an LGTM, PR was merged, no regressions reported, PR was not reverted), without needing extensive tutoring in the process.
|
||||
* You are employed by a company with a history of contributing to Flutter, for the purpose of yourself regularly contributing to Flutter.
|
||||
* You represent a development team that creates applications, plugins, or packages using Flutter and have a close relationship with our developer relations team, including having a customer label, and have a great need to regularly update labels on issues (see [Issue hygiene, Customers](./issue_hygiene/README.md#customers)). (This is rare.)
|
||||
|
||||
Being granted access means that you will be added to the "flutter-hackers" group on GitHub and the "team" role on Discord. This privilege is granted with some expectation of responsibility: contributors are people who care about Flutter and want to help Flutter along our [roadmap](https://github.com/flutter/flutter/wiki/Roadmap). A contributor is not just someone who can make changes or comment on issues, but someone who has demonstrated their ability to collaborate with the team, get the most knowledgeable people to review code, contribute high-quality code, follow through to fix bugs (in code or tests), and provide meaningful insights on issues.
|
||||
Being granted access means that you will be added to the "flutter-hackers" group on GitHub and the "team" role on Discord. This privilege is granted with some expectation of responsibility: contributors are people who care about Flutter and want to help Flutter along our [roadmap](../roadmap/Roadmap.md). A contributor is not just someone who can make changes or comment on issues, but someone who has demonstrated their ability to collaborate with the team, get the most knowledgeable people to review code, contribute high-quality code, follow through to fix bugs (in code or tests), and provide meaningful insights on issues.
|
||||
|
||||
We grant access optimistically based on a reasonably small volume of evidence of good faith. Correspondingly, we will remove access quickly if we find our trust has been violated. Contributors with commit access must still follow all our processes and policies, and must follow our [code of conduct](https://github.com/flutter/flutter/blob/main/CODE_OF_CONDUCT.md) rigorously. (Please read it, it's stricter than most.)
|
||||
|
||||
|
@ -13,7 +13,7 @@
|
||||
Verify that `adb` is in your [PATH](https://en.wikipedia.org/wiki/PATH_(variable)) (that `which adb` prints sensible output).
|
||||
|
||||
If you're
|
||||
[also working on the Flutter engine](../engine/dev/Setting-up-the-Engine-development-environment.md),
|
||||
[also working on the Flutter engine](../engine/contributing/Setting-up-the-Engine-development-environment.md),
|
||||
you can use the copy of the Android platform tools in
|
||||
`.../engine/src/third_party/android_tools/sdk/platform-tools`.
|
||||
|
||||
@ -57,8 +57,8 @@
|
||||
|
||||
Next steps:
|
||||
|
||||
* [Running examples](https://github.com/flutter/flutter/wiki/Running-examples), to see if your setup works.
|
||||
* [The flutter tool](https://github.com/flutter/flutter/wiki/The-flutter-tool), to learn about how the `flutter` command line tool works.
|
||||
* [Running examples](../examples/Running-examples.md), to see if your setup works.
|
||||
* [The flutter tool](../tool/README.md), to learn about how the `flutter` command line tool works.
|
||||
* [Style guide for Flutter repo](Style-guide-for-Flutter-repo.md), to learn how to write code for Flutter.
|
||||
* [Tree hygiene](Tree-hygiene.md), to learn about how to submit patches.
|
||||
* [Signing commits](Signing-commits.md), to configure your environment to securely sign your commits.
|
||||
|
@ -95,10 +95,10 @@ proper fix for a problem rather than just applying a band-aid.
|
||||
When you fix a bug, first write a test that fails, then fix the bug
|
||||
and verify the test passes.
|
||||
|
||||
When you implement a new feature, write tests for it. (See also: https://github.com/flutter/flutter/wiki/Running-and-writing-tests[Running and writing tests], and the section on writing tests below.)
|
||||
When you implement a new feature, write tests for it. (See also: [Running and writing tests](./testing/Running-and-writing-tests.md), and the section on writing tests below.)
|
||||
|
||||
Check the code coverage
|
||||
to make sure every line of your new code is tested. See also: https://github.com/flutter/flutter/wiki/Test-coverage-for-package%3Aflutter[Test coverage for package:flutter].
|
||||
to make sure every line of your new code is tested. See also: [Test coverage for package:flutter](./testing/Test-coverage-for-package-flutter.md).
|
||||
|
||||
If something isn't tested, it is very likely to regress or to get "optimized away".
|
||||
If you want your code to remain in the codebase, you should make sure to test it.
|
||||
@ -292,9 +292,9 @@ by real developers.
|
||||
|
||||
### Get early feedback when designing new APIs
|
||||
|
||||
If you're designing a new API or a new feature, consider https://github.com/flutter/flutter/wiki/Chat#design-documents[writing a design doc].
|
||||
If you're designing a new API or a new feature, consider [writing a design doc](Design-Documents.md).
|
||||
Then, get feedback from the relevant people, e.g. send it to `flutter-dev` or
|
||||
post it on the https://github.com/flutter/flutter/wiki/Chat#existing-channels[relevant chat channel].
|
||||
post it on the [relevant chat channel](Chat.md#existing-channels).
|
||||
|
||||
|
||||
### Start designing APIs from the closest point to the developer
|
||||
@ -327,7 +327,7 @@ Put yourself in the shoes of whoever sees that error message. Why did they see i
|
||||
|
||||
### Template values should set developers up for success
|
||||
|
||||
Template defaults should focus on providing the best developer experience. Templates should help developers understand the code, be easy to run now and support in the future. Help developers by picking dependencies that are broadly used and/or broadly supported and by leaving https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#leave-breadcrumbs-in-the-comments[comments that are helpful].
|
||||
Template defaults should focus on providing the best developer experience. Templates should help developers understand the code, be easy to run now and support in the future. Help developers by picking dependencies that are broadly used and/or broadly supported and by leaving [comments that are helpful](#leave-breadcrumbs-in-the-comments).
|
||||
|
||||
See flutter create's templates for an example.
|
||||
|
||||
@ -376,7 +376,7 @@ All licenses included in this manner must have been reviewed and determined to b
|
||||
|
||||
All such "third party code" must either be a fork for which we take full responsibility, or there must be an automated rolling mechanism that keeps the code up to date when the upstream source changes.
|
||||
|
||||
In general it is _strongly_ recommended that we avoid any such code unless strictly necessary. In particular, we aim for all code in the flutter/flutter repository to be https://github.com/flutter/flutter/wiki/Why-we-have-a-separate-engine-repo#licensing?[single-licensed], which is why it does not contain any "third party code" at all.
|
||||
In general it is _strongly_ recommended that we avoid any such code unless strictly necessary. In particular, we aim for all code in the flutter/flutter repository to be [single-licensed](../about/Why-we-have-a-separate-engine-repo.md#licensing), which is why it does not contain any "third party code" at all.
|
||||
|
||||
|
||||
## Documentation (dartdocs, javadocs, etc)
|
||||
@ -651,7 +651,7 @@ The first two arguments are the video's width and height. These should be `560`
|
||||
|
||||
### Clearly mark deprecated APIs
|
||||
|
||||
We have conventions around deprecation. See the https://github.com/flutter/flutter/wiki/Tree-hygiene#deprecation[Tree Hygiene] page for more details.
|
||||
We have conventions around deprecation. See the [Tree Hygiene](Tree-hygiene.md#deprecations) page for more details.
|
||||
|
||||
|
||||
### Use `///` for public-quality private documentation
|
||||
|
@ -1,6 +1,6 @@
|
||||
## tl;dr
|
||||
|
||||
- Regressions should be [reverted first](https://github.com/flutter/flutter/wiki/Landing-Changes-With-Autosubmit) and questions asked later. Bringing the tree to green is higher priority.
|
||||
- Regressions should be [reverted first](../infra/Landing-Changes-With-Autosubmit.md) and questions asked later. Bringing the tree to green is higher priority.
|
||||
- A breaking change is one that breaks the tests in the flutter/tests repo, and those need a migration guide.
|
||||
- Expect that a new patch will be reviewed within two weeks, unless it is fixing a P0 bug in which case it should be reviewed the same day. If it has not been reviewed in that timeframe, reach out on [Chat](Chat.md). Remember that reviewers are human beings with additional professional and personal responsibilities.
|
||||
|
||||
@ -111,7 +111,7 @@ Feel free to update the bot's logic to catch more cases that should be automatic
|
||||
## Using git
|
||||
|
||||
Assuming your environment has been configured according to the instructions in
|
||||
[Setting up the Engine development environment](../engine/dev/Setting-up-the-Engine-development-environment.md),
|
||||
[Setting up the Engine development environment](../engine/contributing/Setting-up-the-Engine-development-environment.md),
|
||||
[Setting up the Framework development environment](Setting-up-the-Framework-development-environment.md), or
|
||||
[Setting up the Packages development environment](../ecosystem/contributing/Setting-up-the-Packages-development-environment.md),
|
||||
follow these steps to start working on a patch:
|
||||
@ -187,7 +187,7 @@ saying what your patch does and providing a link.
|
||||
|
||||
### Who
|
||||
|
||||
PRs are assigned reviewers weekly. The precise process varies by team but tends to be combined with issue [triage](https://github.com/flutter/flutter/wiki/Triage).
|
||||
PRs are assigned reviewers weekly. The precise process varies by team but tends to be combined with issue [triage](../triage/README.md).
|
||||
|
||||
Code should be reviewed by the owner (tech lead) of the area(s) of the codebase that you are changing,
|
||||
or someone to whom they have delegated that authority.
|
||||
@ -283,7 +283,7 @@ revert (roll back) the check-in (even if it isn't yours). Do not attempt to forw
|
||||
|
||||
There is no shame in making mistakes! Reverts happen all the time and are a normal part of engineering.
|
||||
|
||||
To revert a PR, just add the `revert` label to it. _For more details, see [Landing Changes With Autosubmit](https://github.com/flutter/flutter/wiki/Landing-Changes-With-Autosubmit)._
|
||||
To revert a PR, just add the `revert` label to it. _For more details, see [Landing Changes With Autosubmit](../infra/Landing-Changes-With-Autosubmit.md)._
|
||||
|
||||
|
||||
### Avoid "Revert "Revert "Revert "Revert "Fix foo"""" commit messages
|
||||
@ -334,7 +334,7 @@ way or have determined it is an acceptable trade-off).
|
||||
### Performance regressions caused by auto-roller commits
|
||||
|
||||
Although reverting a normal commit that caused performance regressions is the default
|
||||
behavior, reverting an [auto-roller](https://github.com/flutter/flutter/wiki/Autorollers)
|
||||
behavior, reverting an [auto-roller](../infra/Autorollers.md)
|
||||
(e.g., an engine-roller commit like https://github.com/flutter/flutter/commit/fdcb57b69eff2162e9aead6dec0f8058788e7608)
|
||||
commit could cause some complications:
|
||||
|
||||
@ -383,7 +383,7 @@ Implement the change you wish to see and run the existing tests against your new
|
||||
The "contributed tests" are:
|
||||
|
||||
* Those in the [`customer_testing`](https://github.com/flutter/tests) shard on `flutter/flutter` PRs.
|
||||
* Additional test suites that we have been allowed to run but that are not public. (Notably, Google allows us to run several tens of thousands of [proprietary tests](https://github.com/flutter/flutter/wiki/Understanding-Google-Testing) on each commit.)
|
||||
* Additional test suites that we have been allowed to run but that are not public. (Notably, Google allows us to run several tens of thousands of [proprietary tests](../infra/Understanding-Google-Testing.md) on each commit.)
|
||||
|
||||
There are no exemptions to this policy, because these tests run in our CI and breaking them will close the tree.
|
||||
|
||||
|
@ -9,7 +9,7 @@ This page attempts to be a one-stop shop for figuring out what the most importan
|
||||
1. Performance regressions. Check the [dashboard](https://flutter-dashboard.appspot.com/benchmarks.html) for new unreported regressions and see GitHub for the list of [reported performance regressions](https://github.com/flutter/flutter/issues?utf8=%E2%9C%93&q=is%3Aopen+label%3A%22c%3A+performance%22+label%3A%22c%3A+regression%22+).
|
||||
1. [Other regressions](https://github.com/flutter/flutter/issues?q=is%3Aopen+is%3Aissue+label%3A%22c%3A+regression%22).
|
||||
1. Reducing technical debt. (For example, increasing [our test coverage](./testing/Test-coverage-for-package-flutter.md) by [writing new tests](./testing/Running-and-writing-tests.md), or fixing TODOs.)
|
||||
1. [P2 issues](https://github.com/flutter/flutter/labels/P1), which correspond to the remaining areas of our [roadmap](https://github.com/flutter/flutter/wiki/Roadmap), such as:
|
||||
1. [P2 issues](https://github.com/flutter/flutter/labels/P1), which correspond to the remaining areas of our [roadmap](../roadmap/Roadmap.md), such as:
|
||||
* Bugs marked as [annoyances](https://github.com/flutter/flutter/issues?q=is%3Aopen+is%3Aissue+label%3A%22a%3A+annoyance%22+sort%3Areactions-%2B1-desc).
|
||||
* Bugs labeled as issues of [quality](https://github.com/flutter/flutter/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3A%22a%3A+quality%22+sort%3Areactions-%2B1-desc+).
|
||||
* Bugs with the [crash](https://github.com/flutter/flutter/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3A%22c%3A+crash%22+sort%3Areactions-%2B1-desc+) label.
|
||||
@ -18,7 +18,7 @@ This page attempts to be a one-stop shop for figuring out what the most importan
|
||||
|
||||
Bugs in other bug systems should be tracked with bugs in GitHub. OKRs should be reflected in the items listed above. For example, OKRs should reflect what the roadmap covers, expected customer blockers, and so forth. Work that is unique to a particular quarter would be represented by a filed bug with a milestone and assignee.
|
||||
|
||||
During [triage](https://github.com/flutter/flutter/wiki/Triage), bugs should be prioritized according to the [P0-P3 labels](./issue_hygiene/README.md#priorities) so as to fit the order described above.
|
||||
During [triage](../triage/README.md), bugs should be prioritized according to the [P0-P3 labels](./issue_hygiene/README.md#priorities) so as to fit the order described above.
|
||||
|
||||
Sometimes, items in the list above escalate. For example, a bug might get filed as a P2 issue, then be recognized as a critical regression and upgraded to P0.
|
||||
|
||||
|
@ -250,7 +250,7 @@ and senior leads want resolved to the attention of the appropriate engineering
|
||||
team.
|
||||
|
||||
The `customer: crowd` label is used to represent bugs that are affecting large
|
||||
numbers of people; during initial [Triage](https://github.com/flutter/flutter/wiki/Triage), high-profile bugs get labeled in
|
||||
numbers of people; during initial [Triage](../../triage/README.md), high-profile bugs get labeled in
|
||||
this way to bring them to the attention of the engineering team. "Large numbers"
|
||||
is a judgement call. If dozens of people independently run into the same issue
|
||||
and file a bug and we end up realizing that they're all duplicates of each other,
|
||||
@ -336,7 +336,7 @@ If you have an idea that you would like to land, the recommended process is:
|
||||
|
||||
Avoid filing issues that are on vague topics without a clear problem description.
|
||||
|
||||
Please close issues that are not actionable. See [Triage](https://github.com/flutter/flutter/wiki/Triage) for more details.
|
||||
Please close issues that are not actionable. See [Triage](../../triage/README.md) for more details.
|
||||
|
||||
#### Issues should have clear steps to reproduce
|
||||
|
||||
@ -349,12 +349,12 @@ If an issue is lacking this information, request it from the commenter and close
|
||||
An issue should be closed if:
|
||||
|
||||
* it is fixed!
|
||||
* it is a [duplicate](https://github.com/flutter/flutter/wiki/Triage#duplicates).
|
||||
* it is a [duplicate](../../triage/README.md#duplicates).
|
||||
* it makes multiple requests which could be addressed independently. Encourage people to file separate bugs for each independent item.
|
||||
* it is describing a _solution_ rather than a _problem_. For example, it has no use cases, and the use cases are not obvious, or might have other solutions.
|
||||
* it is not [actionable](https://github.com/flutter/flutter/wiki/Triage#what-makes-an-issue-actionable) and does not [have unusual symptoms](https://github.com/flutter/flutter/wiki/Triage#unactionable-bugs-with-unusual-symptoms). This covers a wide variety of cases, such as invalid bugs, bugs without steps to reproduce, bugs that have become irrelevant, or bugs that are unclear and which the reporter has not offered more details for. It also includes non-catastrophic bugs that cannot be reproduced by anyone but the original reporter. For this latter case, encourage the reporter to attempt to debug the issue themselves, potentially giving suggestions for places where they could instrument the code to find the issue, and invite them to join the Discord for help; then add the `waiting for customer response` label. The issue will get automatically closed after a few weeks if they don't respond.
|
||||
* it is not [actionable](../../triage/README.md#what-makes-an-issue-actionable) and does not [have unusual symptoms](../../triage/README.md#unactionable-bugs-with-unusual-symptoms). This covers a wide variety of cases, such as invalid bugs, bugs without steps to reproduce, bugs that have become irrelevant, or bugs that are unclear and which the reporter has not offered more details for. It also includes non-catastrophic bugs that cannot be reproduced by anyone but the original reporter. For this latter case, encourage the reporter to attempt to debug the issue themselves, potentially giving suggestions for places where they could instrument the code to find the issue, and invite them to join the Discord for help; then add the `waiting for customer response` label. The issue will get automatically closed after a few weeks if they don't respond.
|
||||
* it is a feature request that we are unlikely to ever address, and if we did address it, it would not be part of the core SDK (e.g. it would be in a package). (For example, anything in the [`would be a good package` `P3`](https://github.com/flutter/flutter/issues?q=is%3Aopen+is%3Aissue+label%3A%22would+be+a+good+package%22+label%3AP3) list is a good candidate for closing without fixing.)
|
||||
* we would not accept a fix even if one were to be offered ([e.g. support for platforms at level of support 4](https://github.com/flutter/flutter/wiki/Values#levels-of-support)).
|
||||
* we would not accept a fix even if one were to be offered ([e.g. support for platforms at level of support 4](../../about/Values.md#levels-of-support)).
|
||||
* it is an issue regarding internal processes, tooling, or infrastructure (i.e. something that our users are not affected by), that we have no plans to get to (e.g. that would be marked P3). (For example, anything in the [`c: tech-debt` `P3`](https://github.com/flutter/flutter/issues?q=is%3Aopen+is%3Aissue+label%3A%22c%3A+tech-debt%22+label%3AP3) list is a good candidate for closing.)
|
||||
* it is tracking technical debt but the suggested improvements are marginal at best or would require significant research to be evaluated. Prefer having folks who work in the relevant part of the code make improvements based on their judgment.
|
||||
|
||||
@ -384,4 +384,4 @@ If you need to track some work item, you can file a bug and assign it to yoursel
|
||||
|
||||
When a test flakes, a P0 bug is automatically filed with the label [`team: flakes`](https://github.com/flutter/flutter/issues?q=is%3Aopen+is%3Aissue+label%3A%22team%3A+flakes%22+sort%3Aupdated-asc). This issue should be investigated with all due haste, and a priority level should then be assigned to the issue. At any particular time, the most flaky tests should remain P0. However, flakes that are hard to pin down may be downgraded in priority (e.g. to P1). Please do not ignore the issue entirely, however, and make sure to close bugs once they are resolved, even if it's by magic.
|
||||
|
||||
_See also: [Reducing test flakiness](https://github.com/flutter/flutter/wiki/Reducing-Test-Flakiness)_
|
||||
_See also: [Reducing test flakiness](../../infra/Reducing-Test-Flakiness.md)_
|
@ -45,7 +45,7 @@ before the test runs.
|
||||
To run analysis and all the tests for the entire Flutter repository, the same way that Cirrus
|
||||
runs them, run `dart dev/bots/test.dart` and `dart --enable-asserts dev/bots/analyze.dart`.
|
||||
|
||||
If you've built your own flutter engine (see [Setting up the Engine development environment](../../engine/dev/Setting-up-the-Engine-development-environment.md)), you
|
||||
If you've built your own flutter engine (see [Setting up the Engine development environment](../../engine/contributing/Setting-up-the-Engine-development-environment.md)), you
|
||||
can pass `--local-engine` to change what flutter shell `flutter test` uses. For example,
|
||||
if you built an engine in the `out/host_debug_unopt` directory, you can use:
|
||||
|
||||
@ -118,7 +118,7 @@ The following is an example of what running the local engine command might look
|
||||
|
||||
The above command would use the local Flutter engine located at `/Users/myname/flutter/engine` to execute the `external_ui_integration_test` test on an Android emulator, which is why the `android_debug_unopt_x86` version of the engine is used.
|
||||
|
||||
Note that some tests may require `profile` mode instead of `debug` mode when running with local engine. Make sure to pass in the correct local engine. See [Compiling the engine](../../engine/dev/Compiling-the-engine.md) for more details.
|
||||
Note that some tests may require `profile` mode instead of `debug` mode when running with local engine. Make sure to pass in the correct local engine. See [Compiling the engine](../../engine/contributing/Compiling-the-engine.md) for more details.
|
||||
|
||||
## For the engine
|
||||
|
||||
|
@ -1,7 +1,7 @@
|
||||
This is an index of team-facing documentation for the [flutter/packages repository](https://github.com/flutter/packages/).
|
||||
|
||||
- [Contributing to Plugins and Packages](contributing/README.md)
|
||||
- [Flutter migrate](https://github.com/flutter/flutter/wiki/Flutter-migrate)
|
||||
- [Flutter migrate](../wiki_archive/Flutter-migrate.md)
|
||||
- [Package migration to 1.0.0](Package-migration-to-1.0.0.md)
|
||||
- [Plugin Tests](testing/Plugin-Tests.md)
|
||||
- [Plugins and Packages repository structure](Plugins-and-Packages-repository-structure.md)
|
||||
|
@ -1,4 +1,4 @@
|
||||
This page covers additional information that is specific to contributing to flutter/packages. If you aren't already familiar with the general guidance on Flutter contribution, start with [Tree hygiene](https://github.com/flutter/flutter/wiki/Tree-hygiene).
|
||||
This page covers additional information that is specific to contributing to flutter/packages. If you aren't already familiar with the general guidance on Flutter contribution, start with [Tree hygiene](../../contributing/Tree-hygiene.md).
|
||||
|
||||
## Version and CHANGELOG updates
|
||||
|
||||
@ -178,12 +178,12 @@ On some platforms, there are multiple native languages that can be used to write
|
||||
- Currently our policy is to have a limited number of plugins in Kotlin, to ensure that we are finding Kotlin-specific plugin issues in our own development.
|
||||
- Java if the plugin is already in Java (which is almost all of them).
|
||||
- Allowing Kotlin more broadly is [under consideration](https://docs.google.com/document/d/1Ok_mUPgmw8_l-ynLueEKtXm2Fs48lEVB0JqZd7M7uyA/edit?usp=sharing), but currently most plugin development is limited to Java to avoid adding another language to the set of languages Flutter team members need to interact with regularly.
|
||||
- If you are interested in taking on a **long-term ownership role in a plugin**, and would like to migrate it to Kotlin, please reach out in the `hackers-ecosystem` channel [on Discord](https://github.com/flutter/flutter/wiki/Chat).
|
||||
- If you are interested in taking on a **long-term ownership role in a plugin**, and would like to migrate it to Kotlin, please reach out in the `hackers-ecosystem` channel [on Discord](../../contributing/Chat.md).
|
||||
- iOS: Depends on the plugin. The goal is to eventually migrate all plugins to Swift; see [the migration section below](#swift-migration-for-1p-plugins) for details. For non-migration PRs, use:
|
||||
- Swift if the plugin is entirely Swift.
|
||||
- Swift or Objective-C if the plugin is partially migrated.
|
||||
- Objective-C if the plugin is still entirely Objective-C.
|
||||
- Linux: C. Use of C++ constructs is strongly discouraged; see [repo style notes](https://github.com/flutter/packages/blob/main/CONTRIBUTING.md#style) for details
|
||||
- Linux: C. Use of C++ constructs is strongly discouraged; see [repo style notes](../../../CONTRIBUTING.md#style) for details
|
||||
- macOS: Swift only\*.
|
||||
- \* In some cases an existing iOS implementation has been updated to support macOS, so is Objective-C (e.g., `in_app_purchase`). This is the only case where Objective-C is allowed for macOS plugins.
|
||||
- Windows: C++.
|
||||
|
@ -1 +1 @@
|
||||
The flutter/plugins repository is no longer in use. See [Setting up the Packages development environment](https://github.com/flutter/flutter/wiki/Setting-up-the-Packages-development-environment) instead.
|
||||
The flutter/plugins repository is no longer in use. See [Setting up the Packages development environment](Setting-up-the-Packages-development-environment.md) instead.
|
@ -9,7 +9,7 @@ This page describes the process of updating flutter/packages after a stable Flut
|
||||
|
||||
`dart run script/tool/bin/flutter_plugin_tools.dart update-min-sdk --flutter-min=3.7.0`
|
||||
|
||||
* Per [repo policy](https://github.com/flutter/flutter/wiki/Contributing-to-Plugins-and-Packages#version), we do not version-bump these changes, so the associated `update-release-info` command should use `--version=next`. A convenient way to run the `update-release-info` command on only the necessary packages is to make the `update-min-sdk` run its own commit, then use `--base-branch HEAD^ --run-on-changed-packages` to target only the packages changed in that commit.
|
||||
* Per [repo policy](../contributing/README.md#version), we do not version-bump these changes, so the associated `update-release-info` command should use `--version=next`. A convenient way to run the `update-release-info` command on only the necessary packages is to make the `update-min-sdk` run its own commit, then use `--base-branch HEAD^ --run-on-changed-packages` to target only the packages changed in that commit.
|
||||
* This must be done in the same PR as the previous step, or CI will fail.
|
||||
* The [release action](https://github.com/flutter/packages/blob/e7d812cefce083fa09762d25cd42303737d05b9f/.github/workflows/release.yml#L34) should be updated to use the new stable.
|
||||
|
||||
|
@ -1,4 +1,4 @@
|
||||
*If you haven't already read it, start with [the repository structure overview](https://github.com/flutter/flutter/wiki/Plugins-and-Packages-repository-structure) to familiarize yourself with the types of packages discussed below.*
|
||||
*If you haven't already read it, start with [the repository structure overview](../Plugins-and-Packages-repository-structure.md) to familiarize yourself with the types of packages discussed below.*
|
||||
|
||||
## Types of Tests
|
||||
|
||||
@ -131,7 +131,7 @@ flutter pub run build_runner build
|
||||
|
||||
## Adding tests
|
||||
|
||||
A PR changing a plugin [should add tests](https://github.com/flutter/flutter/wiki/Tree-hygiene#tests). Which type(s) of tests you should add will depend on what exactly you are changing. See below for some high-level guidance, but if you're not sure please ask in your PR or in `#hackers-ecosystem` [on Discord](https://github.com/flutter/flutter/wiki/Chat).
|
||||
A PR changing a plugin [should add tests](../../contributing/Tree-hygiene.md#tests). Which type(s) of tests you should add will depend on what exactly you are changing. See below for some high-level guidance, but if you're not sure please ask in your PR or in `#hackers-ecosystem` [on Discord](../../contributing/Chat.md).
|
||||
Hopefully the scaffolding to run the necessary kinds of tests are already in place for that plugin, in which case you just add tests to the existing files in the locations referenced above. If not, see below for more information about adding test scaffolding.
|
||||
|
||||
### FAQ: Do I need to add tests even if the part of the code I'm changing isn't already tested?
|
||||
@ -170,7 +170,7 @@ Some patterns to consider given all of the above:
|
||||
If a plugin is missing test scaffolding for the type of tests you want to add, you have several options:
|
||||
- If it's simple to enable them, and you are comfortable making the changes, you can enable them as part of your PR.
|
||||
- If it's non-trivial to enable them, but you are comfortable doing it, you can make a new PR that enables them with some minimal test, and ask for that to be reviewed and landed before continuing with your PR.
|
||||
- If you aren't comfortable making the change, reach out [via Discord](https://github.com/flutter/flutter/wiki/Chat) and ask in `#hackers-ecosystem`.
|
||||
- If you aren't comfortable making the change, reach out [via Discord](../../contributing/Chat.md) and ask in `#hackers-ecosystem`.
|
||||
|
||||
Regardless of the approach you use, please reach out on Discord if a PR that sets up a new kind of test doesn't get reviewed within two weeks. Filling in the gaps in test scaffolding is a priority for the team, so we want to review such PRs quickly whenever possible.
|
||||
|
||||
|
@ -16,7 +16,7 @@ flutter/packages uses the same LUCI infrastructure as most of the rest of Flutte
|
||||
|
||||
### LUCI
|
||||
|
||||
This is the CI system used by flutter/flutter and flutter/engine. For information about LUCI results pages, see [Understanding a LUCI build failure](https://github.com/flutter/flutter/wiki/Understanding-a-LUCI-build-failure).
|
||||
This is the CI system used by flutter/flutter and flutter/engine. For information about LUCI results pages, see [Understanding a LUCI build failure](../../infra/Understanding-a-LUCI-build-failure.md).
|
||||
|
||||
#### Results
|
||||
|
||||
@ -40,7 +40,7 @@ GitHub Actions tasks are configured in `.github/workflows/`.
|
||||
|
||||
The overall testing structure for flutter/packages is:
|
||||
- Most tests are run on only one host platform: Linux when possible, or the relevant platform if necessary (e.g., Windows target tests must run on Windows hosts, and iOS and macOS tests must run on macOS hosts).
|
||||
- Most tests are run with both Flutter `master` and Flutter `stable` (see [discussion of supported platforms](https://github.com/flutter/flutter/wiki/Contributing-to-Plugins-and-Packages#supported-flutter-versions) for more details).
|
||||
- Most tests are run with both Flutter `master` and Flutter `stable` (see [discussion of supported platforms](../contributing/README.md#supported-flutter-versions) for more details).
|
||||
- Since in practice `stable`-only failures are very rare, CI is currently configured to only run `stable` in post-submit to reduce CI time and costs.
|
||||
- Architecture coverage is as-needed; we generally don't duplicate tests across architectures. For plugins, where architecture is most likely to be an issue, we try to run:
|
||||
- the majority of the tests (`*_platform_tests`) on the most popular architecture, and
|
||||
@ -56,25 +56,25 @@ Exclusions **must** include explanatory comments, and in cases where they are no
|
||||
|
||||
# Specific tests
|
||||
|
||||
In addition to Dart unit tests, Dart integration tests, and for plugins the various kinds of [native plugin tests](https://github.com/flutter/flutter/wiki/Plugin-Tests), there are a number of tests that check for repository best practices or to catch problems that have affected packages in the past. As a rule of thumb, any time we find a bug or mistake only *after* publishing a package, we try to add a check for that in CI to prevent similar issues in the future.
|
||||
In addition to Dart unit tests, Dart integration tests, and for plugins the various kinds of [native plugin tests](Plugin-Tests.md), there are a number of tests that check for repository best practices or to catch problems that have affected packages in the past. As a rule of thumb, any time we find a bug or mistake only *after* publishing a package, we try to add a check for that in CI to prevent similar issues in the future.
|
||||
|
||||
Below are descriptions of many of the less self-evident CI tests, and common solution to failures. Anyone adding new tests is encouraged to document them here.
|
||||
|
||||
- **`submit-queue`**: This only shows in PRs (presubmit), and reflects the current state of the tree: if it is red, the tree is currently closed to commits (which can mean either that the tree is red, or that a recently landed PR is still running post-submit tests), and if it is green the tree is open. This has **no relation** to the PR itself, and as a PR author you do not need to do anything about it; Flutter team members monitor the state of the tree, and will handle failures.
|
||||
- There is a known issue that sometimes causes the status of this check to be stale; the causes is unknown. If this happens (i.e., the check in red but the tree state as described in the Infrastructure section above is actually green), you an either update your PR by merging in the latest `main` to force updates, or you can reach out to a Flutter team member (in a comment on the PR, or in Discord) to override the incorrect check.
|
||||
- **`*_platform_tests`**: This runs each package's integration tests on the given target platform, as well as any [native plugin tests](https://github.com/flutter/flutter/wiki/Plugin-Tests) for that platform. This can also include native-language-specific analysis or lint checks.
|
||||
- **`*_platform_tests`**: This runs each package's integration tests on the given target platform, as well as any [native plugin tests](Plugin-Tests.md) for that platform. This can also include native-language-specific analysis or lint checks.
|
||||
- **`analyze`**: The initial `analyze` step is a straightforward Dart `analyze` run, but the `pathified_analyze` step is more complicated; it is intended to find issues that will cause out-of-band breakage in our own repository when the change being tested is published (most commonly with federated plugins). It does this by finding all packages that have non-breaking-version changes in the PR, and then rewriting all references to those packages in the repository to be `path:` dependencies, then re-running analysis.
|
||||
|
||||
A failure here does not necessarily mean that the PR is wrong; because we use very strict analysis options, changes that are not considered breaking by Dart semver conventions can break our CI. Common sources of failures here include:
|
||||
- Accidentally making a breaking change without making a major version change to the plugin.
|
||||
- **Solution**: Fix the versioning.
|
||||
- Deprecating something that is still in use by another package within the repository.
|
||||
- **Solution**: Suppress the warnings with `// ignore: deprecated_member_use` annotations in the other packages using that method, [with a comment](https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#comment-all--ignores) linking to the issue that tracks updating it. Once it lands, do a follow-up PR to update the calls and remove the `ignore`s.
|
||||
- **Solution**: Suppress the warnings with `// ignore: deprecated_member_use` annotations in the other packages using that method, [with a comment](../../contributing/Style-guide-for-Flutter-repo.md#comment-all--ignores) linking to the issue that tracks updating it. Once it lands, do a follow-up PR to update the calls and remove the `ignore`s.
|
||||
- Adding a new enum value. We generally do not consider this breaking, but use your judgement and discuss with your reviewer; consider whether it is likely that clients have critical logic that depends on exhaustively handling all enum values, and what the effects are likely to be for those use cases if a new value is added.
|
||||
- **Solution**: If it's not treated as breaking, then temporary disable that analyzer warning while adding the value:
|
||||
* In the PR that adds the value, suppress the warnings with `// ignore: exhaustive_cases` annotations, [with a comment](https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#comment-all--ignores) linking to the issue that tracks updating it.
|
||||
* In the PR that adds the value, suppress the warnings with `// ignore: exhaustive_cases` annotations, [with a comment](../../contributing/Style-guide-for-Flutter-repo.md#comment-all--ignores) linking to the issue that tracks updating it.
|
||||
* In the follow-up PR that picks up the new enum value and uses it, remove the `ignore`.
|
||||
- **`legacy_version_analyze`**: Runs `analyze` with older versions of Flutter than the current `stable` on any package that claims to support them; see [the supported version policy](https://github.com/flutter/flutter/wiki/Contributing-to-Plugins-and-Packages#supported-flutter-versions) for details.
|
||||
- **`legacy_version_analyze`**: Runs `analyze` with older versions of Flutter than the current `stable` on any package that claims to support them; see [the supported version policy](../contributing/README.md#supported-flutter-versions) for details.
|
||||
- **Solution**: Unless you have a specific need to keep support for the old version (unlikely), just update the Flutter constraint in `pubspec.yaml` to exclude the failing version(s) of Flutter.
|
||||
- **`analyze_downgraded`**: Runs `analyze` after running a `pub downgrade`, to ensure that minimum constraints are correct (e.g., that you don't add usage of an API from version `x.1` of a dependency that is specified as `^x.0` in `pubspec.yaml`).
|
||||
- **Solution**: Update the relevant constraint to the version that introduced the new APIs.
|
||||
@ -84,7 +84,7 @@ Below are descriptions of many of the less self-evident CI tests, and common sol
|
||||
- Otherwise, temporarily add the necessary package(s) to the `exclude_all_packages_app.yaml` exclusion file (see discussion of exclusion files above).
|
||||
- **`repo_checks`**: Enforces various best practices (formatting, style, common mistakes, etc.). In most cases, the error messages should give clear and actionable explanations of what is wrong and how to fix it. Some general notes on specific steps:
|
||||
- **`license_script`**: All code files must have the repository copyright/license block at the top. In most cases a failure here just means you forgot to add the license to a new file.
|
||||
- **`federated_safety_script`**: Changing interdependent sub-packages of a federated plugin in the same PR can mask serious issues, such as undesired breaking changes in platform APIs. See the documentation on [changing federated plugins](https://github.com/flutter/flutter/wiki/Contributing-to-Plugins-and-Packages#changing-federated-plugins) for next steps.
|
||||
- **`federated_safety_script`**: Changing interdependent sub-packages of a federated plugin in the same PR can mask serious issues, such as undesired breaking changes in platform APIs. See the documentation on [changing federated plugins](../contributing/README.md#changing-federated-plugins) for next steps.
|
||||
|
||||
# Out-of-band failures
|
||||
|
||||
@ -111,7 +111,7 @@ LUCI tasks are run on Flutter-infrastructure-managed VMs, using an [out-of-repo
|
||||
- Usually easy to identify since failures are generally before the tests even run.
|
||||
|
||||
#### Investigation & resolution tips
|
||||
- File an [infrastructure ticket](https://github.com/flutter/flutter/wiki/Infra-Ticket-Queue).
|
||||
- File an [infrastructure ticket](../../infra/Infra-Ticket-Queue.md).
|
||||
- Check the recipe file for recent changes.
|
||||
|
||||
### Firebase Test Lab (Also known as: "FTL")
|
||||
|
@ -16,7 +16,7 @@ This is a very low level API and is not suitable for beginners.
|
||||
* The Flutter engine API has no platform specific dependencies, has a stable ABI and is available in its entirety in a [single C header file available here](https://github.com/flutter/engine/blob/main/shell/platform/embedder/embedder.h).
|
||||
* To use as a guide, you may use [this example embedder that uses GLFW](https://github.com/flutter/engine/blob/main/examples/glfw/FlutterEmbedderGLFW.cc) for window management and rendering.
|
||||
|
||||
While we do not object to teams creating custom builds of the Flutter engine for their purposes, we do not support this configuration. Not supporting it means that we do not commit to any timelines for fixing bugs that may come up in such a configuration, even for customers for which we would usually be willing to make commitments (see the [Issue Hygiene](https://github.com/flutter/flutter/wiki/Issue-hygiene) page). It also means that we encourage teams to view such configurations as short-term solutions only and encourage teams to transition away from such configurations at the earliest possible opportunity.
|
||||
While we do not object to teams creating custom builds of the Flutter engine for their purposes, we do not support this configuration. Not supporting it means that we do not commit to any timelines for fixing bugs that may come up in such a configuration, even for customers for which we would usually be willing to make commitments (see the [Issue Hygiene](../contributing/issue_hygiene/README.md) page). It also means that we encourage teams to view such configurations as short-term solutions only and encourage teams to transition away from such configurations at the earliest possible opportunity.
|
||||
|
||||
We do not expect custom engine builds to be long-term sustainable. They are not supported on any platform where we plan to be the publisher of a Flutter runtime distinct from the applications that run on the runtime, and they require significant effort to port to our new target platforms such as Web and desktop. There is also an expensive maintenance burden (for example, if we add new features, a custom engine build would need to be updated to support that feature).
|
||||
|
||||
|
@ -14,7 +14,7 @@ This will produce a Flutter engine configured for AOT mode targeting the host. N
|
||||
|
||||
## Building the Architecture Specific `gen_snapshot`
|
||||
|
||||
The binary that converts Dart code to architecture specific AOT instructions is called `gen_snapshot`. A successful invocation of `gen_snapshot` should produce four binary blobs. These are the Dart VM heap and instructions snapshots as well as the isolate heap and instruction snapshots. Refer to the [wiki article on engine operation in AOT mode](https://github.com/flutter/flutter/wiki/Flutter-engine-operation-in-AOT-Mode) for the purpose of these snapshots.
|
||||
The binary that converts Dart code to architecture specific AOT instructions is called `gen_snapshot`. A successful invocation of `gen_snapshot` should produce four binary blobs. These are the Dart VM heap and instructions snapshots as well as the isolate heap and instruction snapshots. Refer to the [wiki article on engine operation in AOT mode](Flutter-engine-operation-in-AOT-Mode.md) for the purpose of these snapshots.
|
||||
|
||||
A specific `gen_snapshot` can only produce AOT instructions for one target architecture. To verify that the `gen_snapshot` you have is producing instructions for the architecture you care about, invoke the same with the `--version` flag. It should produce something like the following.
|
||||
|
||||
@ -51,7 +51,7 @@ flutter --local-engine <local_engine_configuration> --local-engine-host <local_h
|
||||
```
|
||||
|
||||
**Note:** The `--local-engine` (and `--local-engine-host`) flag is technically optional. However, not specifying the flag will make the tools pick the released version on of the Flutter engine. This version may contain subtle version mismatches with the engine you are using to prepare the `gen_snapshot` binary. So it is safer to just make sure the version are the same.
|
||||
See [running with a local engine](https://github.com/flutter/flutter/wiki/Debugging-the-engine#running-a-flutter-app-with-a-local-engine) for more details.
|
||||
See [running with a local engine](Debugging-the-engine.md#running-a-flutter-app-with-a-local-engine) for more details.
|
||||
|
||||
The result of the invocation will be the generation of the following binary blobs in the `build/aot directory`:
|
||||
|
||||
|
@ -4,7 +4,7 @@ See also [Crashes](Crashes.md) for advice on handling engine crashes (specifical
|
||||
|
||||
## Running a Flutter app with a local engine
|
||||
|
||||
First, make sure the appropriate version of the engine is built (see [Compiling the engine](./dev/Compiling-the-engine.md)).
|
||||
First, make sure the appropriate version of the engine is built (see [Compiling the engine](./contributing/Compiling-the-engine.md)).
|
||||
|
||||
### Using the Flutter tool
|
||||
|
||||
@ -19,7 +19,7 @@ to run an app with the local engine where `XXXX` should be replaced with the ver
|
||||
> 💡 **TIP**: When developing on a Mac with ARM (M CPU), use `--local-engine-host=host_debug_unopt_arm64`.
|
||||
>
|
||||
> You can continue to use `host_debug_unopt` (required for Intel Macs), but the engine will be run under Rosetta
|
||||
> which may be slower. See [Developing with Flutter on Apple Silicon](https://github.com/flutter/flutter/wiki/Developing-with-Flutter-on-Apple-Silicon)
|
||||
> which may be slower. See [Developing with Flutter on Apple Silicon](../platforms/desktop/macos/Developing-with-Flutter-on-Apple-Silicon.md)
|
||||
> for more information.
|
||||
|
||||
|
||||
@ -47,7 +47,7 @@ You will need to add a new [launch configuration](https://code.visualstudio.com/
|
||||
|
||||
## Bisecting a roll failure
|
||||
|
||||
If the engine roll is failing (see [Autorollers](https://github.com/flutter/flutter/wiki/Autorollers)), you can use `git bisect` on the engine repo to track down the offending commit, using the `--local-engine` and `--local-engine-host` arguments as described above to run the failing framework test with each version of the engine.
|
||||
If the engine roll is failing (see [Autorollers](../infra/Autorollers.md)), you can use `git bisect` on the engine repo to track down the offending commit, using the `--local-engine` and `--local-engine-host` arguments as described above to run the failing framework test with each version of the engine.
|
||||
|
||||
## Tracing OpenGL calls in Skia
|
||||
|
||||
|
@ -30,4 +30,4 @@ In [devicelab](https://github.com/flutter/flutter/tree/main/dev/devicelab) we ru
|
||||
|
||||
## Comparing AOT Snapshot Sizes
|
||||
|
||||
A detailed comparison of AOT snapshot sizes can be performed using the [instructions documented here](https://github.com/flutter/flutter/wiki/Comparing-AOT-Snapshot-Sizes).
|
||||
A detailed comparison of AOT snapshot sizes can be performed using the [instructions documented here](./benchmarks/Comparing-AOT-Snapshot-Sizes.md).
|
@ -10,6 +10,6 @@ ninja -C out/android_jit_release_x86
|
||||
ninja -C out/host_jit_release
|
||||
```
|
||||
|
||||
This can be used with the flutter tool [via the `--local-engine`](https://github.com/flutter/flutter/wiki/Debugging-the-engine#running-a-flutter-app-with-a-local-engine) flag to produce a bundle containing the jit release artifacts using the `flutter assemble` command. By default, flutter.gradle does not know how to package this artifacts so it requires custom integration into a build pipeline. Nevertheless, the artifact structure should be identical to a debug build, but with asserts disabled and product mode enabled.
|
||||
This can be used with the flutter tool [via the `--local-engine`](Debugging-the-engine.md#running-a-flutter-app-with-a-local-engine) flag to produce a bundle containing the jit release artifacts using the `flutter assemble` command. By default, flutter.gradle does not know how to package this artifacts so it requires custom integration into a build pipeline. Nevertheless, the artifact structure should be identical to a debug build, but with asserts disabled and product mode enabled.
|
||||
|
||||
jit_release is not supported on iOS devices. Applications built in JIT mode cannot be distributed on the Apple App Store.
|
@ -48,7 +48,7 @@ TODO(cbracken): write this up using [this patch](https://github.com/flutter/engi
|
||||
[animator]: https://github.com/flutter/engine/blob/main/shell/common/animator.h
|
||||
[drawFrame]: https://api.flutter.dev/flutter/rendering/RendererBinding/drawFrame.html
|
||||
[embedderAPI]: https://github.com/flutter/engine/blob/main/shell/platform/embedder/embedder.h
|
||||
[engineArchThreading]: https://github.com/flutter/flutter/wiki/The-Engine-architecture#threading
|
||||
[engineArchThreading]: ../about/The-Engine-architecture.md#threading
|
||||
[flutterViewRender]: https://api.flutter.dev/flutter/dart-ui/FlutterView/render.html
|
||||
[handleBeginFrame]: https://api.flutter.dev/flutter/scheduler/SchedulerBinding/handleBeginFrame.html
|
||||
[layerTree]: https://github.com/flutter/engine/blob/main/flow/layers/layer_tree.h
|
||||
|
@ -1,15 +1,15 @@
|
||||
This is an index of team-facing documentation for the [flutter/engine repository](https://github.com/flutter/engine/).
|
||||
|
||||
- [Accessibility on Windows](https://github.com/flutter/flutter/wiki/Accessibility-on-Windows)
|
||||
- [Accessibility on Windows](../platforms/desktop/windows/Accessibility-on-Windows.md)
|
||||
- [Code signing metadata](./release/Code-signing-metadata.md) for engine binaries
|
||||
- [Compiling the engine](./dev/Compiling-the-engine.md)
|
||||
- [Compiling the engine](./contributing/Compiling-the-engine.md)
|
||||
- [Comparing AOT Snapshot Sizes](./benchmarks/Comparing-AOT-Snapshot-Sizes.md)
|
||||
- [Crashes](./Crashes.md)
|
||||
- [Custom Flutter engine embedders](./Custom-Flutter-Engine-Embedders.md)
|
||||
- [Custom Flutter Engine Embedding in AOT Mode](./Custom-Flutter-Engine-Embedding-in-AOT-Mode.md)
|
||||
- [Debugging the engine](./Debugging-the-engine.md)
|
||||
- [Flutter engine operation in AOT Mode](./Flutter-engine-operation-in-AOT-Mode.md)
|
||||
- [Flutter Test Fonts](https://github.com/flutter/flutter/wiki/Flutter-Test-Fonts)
|
||||
- [Flutter Test Fonts](../contributing/testing/Flutter-Test-Fonts.md)
|
||||
- [Flutter's modes](./Flutter's-modes.md)
|
||||
- [Engine Clang Tidy Linter](./ci/Engine-Clang-Tidy-Linter.md)
|
||||
- [Engine disk footprint](./Engine-disk-footprint.md)
|
||||
@ -19,14 +19,14 @@ This is an index of team-facing documentation for the [flutter/engine repository
|
||||
- [Impeller](./impeller/README.md) documentation index
|
||||
- [Life of a Flutter Frame](Life-of-a-Flutter-Frame.md)
|
||||
- [Reduce Flutter engine size with MLGO](Reduce-Flutter-engine-size-with-MLGO.md)
|
||||
- [Resolving common build failures](https://github.com/flutter/flutter/wiki/Resolving-common-build-failures)
|
||||
- [Setting up the Engine development environment](./dev/Setting-up-the-Engine-development-environment.md)
|
||||
- [Resolving common build failures](../platforms/android/Resolving-common-build-failures.md)
|
||||
- [Setting up the Engine development environment](./contributing/Setting-up-the-Engine-development-environment.md)
|
||||
- [Supporting legacy platforms](Supporting-legacy-platforms.md)
|
||||
- [Testing Android Changes in the Devicelab on an Emulator](https://github.com/flutter/flutter/wiki/Testing-Android-Changes-in-the-Devicelab-on-an-Emulator)
|
||||
- [Testing Android Changes in the Devicelab on an Emulator](../platforms/android/Testing-Android-Changes-in-the-Devicelab-on-an-Emulator.md)
|
||||
- [Testing the engine](./testing/Testing-the-engine.md)
|
||||
- [Testing presubmit Engine PRs with the Flutter framework](Testing-presubmit-Engine-PRs-with-the-Flutter-framework.md)
|
||||
- [The Engine architecture](../about/The-Engine-architecture.md)
|
||||
- [Upgrading Engine's Android API version](https://github.com/flutter/flutter/wiki/Upgrading-Engine%27s-Android-API-version)
|
||||
- [Upgrading Engine's Android API version](../platforms/android/Upgrading-Engine's-Android-API-version.md)
|
||||
- [Using the Dart Development Service (DDS) and Flutter DevTools with a custom Flutter Engine Embedding](./Using-the-Dart-Development-Service-(DDS)-and-Flutter-DevTools-with-a-custom-Flutter-Engine-Embedding.md)
|
||||
- [Using Sanitizers with the Flutter Engine](./Using-Sanitizers-with-the-Flutter-Engine.md)
|
||||
- [Why we have a separate engine repo](../about/Why-we-have-a-separate-engine-repo.md)
|
||||
|
@ -228,6 +228,6 @@ condition.
|
||||
|
||||
|
||||
[MLGO]: https://github.com/google/ml-compiler-opt
|
||||
[engine setup]: https://github.com/flutter/flutter/wiki/Setting-up-the-Engine-development-environment
|
||||
[compile android]: https://github.com/flutter/flutter/wiki/Compiling-the-engine#compiling-for-android-from-macos-or-linux
|
||||
[engine setup]: ./contributing/Setting-up-the-Engine-development-environment
|
||||
[compile android]: ./contributing/Compiling-the-engine#compiling-for-android-from-macos-or-linux
|
||||
[MLGO demo]: https://github.com/google/ml-compiler-opt/blob/main/docs/demo/demo.md
|
||||
|
@ -1,6 +1,6 @@
|
||||
These instructions can be used to prepare a tabulated summary of the differences in the sizes of two AOT snapshots. The instructions assume that the Flutter Engine has been [setup](https://github.com/flutter/flutter/wiki/Setting-up-the-Engine-development-environment) on the host (at `FLUTTER_ENGINE` in these instructions).
|
||||
These instructions can be used to prepare a tabulated summary of the differences in the sizes of two AOT snapshots. The instructions assume that the Flutter Engine has been [setup](../contributing/Setting-up-the-Engine-development-environment.md) on the host (at `FLUTTER_ENGINE` in these instructions).
|
||||
|
||||
Build the AOT snapshot (`flutter build aot`) for the application but pass in the `--verbose` flag. We need to find the `gen_snapshot` invocation and re-run it with an extra option (`--print-instructions-sizes-to`). If you are instrumenting with a local engine, the `flutter build` [takes a `--local-engine` and `--local-engine-host` flag](https://github.com/flutter/flutter/wiki/Debugging-the-engine#running-a-flutter-app-with-a-local-engine) as well.
|
||||
Build the AOT snapshot (`flutter build aot`) for the application but pass in the `--verbose` flag. We need to find the `gen_snapshot` invocation and re-run it with an extra option (`--print-instructions-sizes-to`). If you are instrumenting with a local engine, the `flutter build` [takes a `--local-engine` and `--local-engine-host` flag](../Debugging-the-engine.md#running-a-flutter-app-with-a-local-engine) as well.
|
||||
|
||||
Here is an example of the updated invocation. Specify the path to a JSON file that acts as a summary (`SUMMARY_LOCATION` in these instructions) as follows.
|
||||
|
||||
@ -22,7 +22,7 @@ Save the file at `SUMMARY_LOCATION` as `before.json`
|
||||
|
||||
Now, either change the Dart code with the changes you wish to see the effects, or, rebuild the engine to create an updated `gen_snapshot` binary.
|
||||
|
||||
After you have made necessary changes, re-run `flutter build aot` again. This step is important because AOT compilation has a [kernel compilation step](https://github.com/flutter/flutter/wiki/Custom-Flutter-Engine-Embedding-in-AOT-Mode#generating-the-kernel-snapshot) before the `gen_snapshot` invocation.
|
||||
After you have made necessary changes, re-run `flutter build aot` again. This step is important because AOT compilation has a [kernel compilation step](../Custom-Flutter-Engine-Embedding-in-AOT-Mode.md#generating-the-kernel-snapshot) before the `gen_snapshot` invocation.
|
||||
|
||||
Re-run the gen_snapshot invocation and save the resulting file to `after.json`.
|
||||
|
||||
|
@ -1,4 +1,4 @@
|
||||
_If you've never built the engine before, first see [Setting up the Engine development environment](https://github.com/flutter/flutter/wiki/Setting-up-the-Engine-development-environment)._
|
||||
_If you've never built the engine before, first see [Setting up the Engine development environment](Setting-up-the-Engine-development-environment.md)._
|
||||
|
||||
# Contents
|
||||
|
||||
@ -43,7 +43,7 @@ source files, pass the flag `--no-prebuilt-dart-sdk` to `//flutter/tools/gn`.
|
||||
|
||||
These steps build the engine used by `flutter run` for Android devices.
|
||||
|
||||
Run the following steps, from the `src` directory created in [Setting up the Engine development environment](https://github.com/flutter/flutter/wiki/Setting-up-the-Engine-development-environment):
|
||||
Run the following steps, from the `src` directory created in [Setting up the Engine development environment](Setting-up-the-Engine-development-environment.md):
|
||||
|
||||
1. `git pull upstream main` in `src/flutter` to update the Flutter Engine repo.
|
||||
|
||||
@ -60,7 +60,7 @@ Run the following steps, from the `src` directory created in [Setting up the Eng
|
||||
> 💡 **TIP**: When developing on a Mac with ARM (M CPU), prefer `host_debug_unopt_arm64`.
|
||||
>
|
||||
> You can continue to use `host_debug_unopt` (required for Intel Macs), but the engine will be run under Rosetta
|
||||
> which may be slower. See [Developing with Flutter on Apple Silicon](https://github.com/flutter/flutter/wiki/Developing-with-Flutter-on-Apple-Silicon)
|
||||
> which may be slower. See [Developing with Flutter on Apple Silicon](../../platforms/desktop/macos/Developing-with-Flutter-on-Apple-Silicon.md)
|
||||
> for more information.
|
||||
|
||||
4. Build your executables
|
||||
@ -80,11 +80,11 @@ If you're going to be debugging crashes in the engine, make sure you add
|
||||
`android/AndroidManifest.xml` file for the Flutter app you are using
|
||||
to test the engine.
|
||||
|
||||
See [The flutter tool](https://github.com/flutter/flutter/wiki/The-flutter-tool) for instructions on how to use the `flutter` tool with a local engine.
|
||||
See [The flutter tool](../../tool/README.md) for instructions on how to use the `flutter` tool with a local engine.
|
||||
You will typically use the `android_debug_unopt` build to debug the engine on a device, and
|
||||
`android_debug_unopt_x64` to debug in on a simulator. Modifying dart sources in the engine will
|
||||
require adding a `dependency_override` section in you app's `pubspec.yaml` as detailed
|
||||
[here](https://github.com/flutter/flutter/wiki/The-flutter-tool#using-a-locally-built-engine-with-the-flutter-tool).
|
||||
[here](../../tool/README.md#using-a-locally-built-engine-with-the-flutter-tool).
|
||||
|
||||
Note that if you use particular android or ios engine build, you will need to have corresponding
|
||||
host build available next to it: if you use `android_debug_unopt`, you should have built `host_debug_unopt`,
|
||||
@ -133,13 +133,13 @@ Run the following steps, from the `src` directory created in the steps above:
|
||||
|
||||
5. `ninja -C out/ios_debug_unopt && ninja -C out/host_debug_unopt` to build all artifacts (use `out/ios_debug_sim_unopt` for Simulator).
|
||||
|
||||
See [The flutter tool](https://github.com/flutter/flutter/wiki/The-flutter-tool) for instructions on how to use the `flutter` tool with a local engine.
|
||||
See [The flutter tool](../../tool/README.md) for instructions on how to use the `flutter` tool with a local engine.
|
||||
You will typically use the `ios_debug_unopt` build to debug the engine on a device, and
|
||||
`ios_debug_sim_unopt` to debug in on a simulator. Modifying dart sources in the engine will
|
||||
require adding a `dependency_override` section in you app's `pubspec.yaml` as detailed
|
||||
[here](https://github.com/flutter/flutter/wiki/The-flutter-tool#using-a-locally-built-engine-with-the-flutter-tool).
|
||||
[here](../../tool/README.md#using-a-locally-built-engine-with-the-flutter-tool).
|
||||
|
||||
See also [instructions for debugging the engine in a Flutter app in Xcode](https://github.com/flutter/flutter/wiki/Debugging-the-engine#debugging-ios-builds-with-xcode).
|
||||
See also [instructions for debugging the engine in a Flutter app in Xcode](../Debugging-the-engine.md#debugging-ios-builds-with-xcode).
|
||||
|
||||
## Compiling for macOS or Linux
|
||||
|
||||
@ -155,10 +155,10 @@ These steps build the desktop embedding, and the engine used by `flutter test` o
|
||||
4. `ninja -C out/host_debug_unopt` to build a desktop unoptimized binary.
|
||||
* If you skipped `--unoptimized`, use `ninja -C out/host_debug` instead.
|
||||
|
||||
See [The flutter tool](https://github.com/flutter/flutter/wiki/The-flutter-tool) for instructions on how to use the `flutter` tool with a local engine.
|
||||
See [The flutter tool](../../tool/README.md) for instructions on how to use the `flutter` tool with a local engine.
|
||||
You will typically use the `host_debug_unopt` build in this setup. Modifying dart sources in the engine will
|
||||
require adding a `dependency_override` section in you app's `pubspec.yaml` as detailed
|
||||
[here](https://github.com/flutter/flutter/wiki/The-flutter-tool#using-a-locally-built-engine-with-the-flutter-tool).
|
||||
[here](../../tool/README.md#using-a-locally-built-engine-with-the-flutter-tool).
|
||||
|
||||
|
||||
## Compiling for Windows
|
@ -92,8 +92,8 @@ gclient sync
|
||||
## Next steps:
|
||||
|
||||
* [Compiling the engine](Compiling-the-engine.md) explains how to actually get builds, now that you have the code.
|
||||
* [The flutter tool](https://github.com/flutter/flutter/wiki/The-flutter-tool) has a section explaining how to use custom engine builds.
|
||||
* [Signing commits](https://github.com/flutter/flutter/wiki/Signing-commits), to configure your environment to securely sign your commits.
|
||||
* [The flutter tool](../../tool/README.md) has a section explaining how to use custom engine builds.
|
||||
* [Signing commits](../../contributing/Signing-commits.md), to configure your environment to securely sign your commits.
|
||||
|
||||
## Editor autocomplete support
|
||||
|
||||
@ -126,7 +126,7 @@ For example, in `src/.vscode/settings.json`:
|
||||
./tools/gn --unopt --mac-cpu arm64 --enable-impeller-vulkan --enable-impeller-opengles --enable-unittests
|
||||
```
|
||||
|
||||
For adding IDE support to the Java code in the engine with VSCode, see ["Using VSCode as an IDE for the Android Embedding"](https://github.com/flutter/flutter/wiki/Setting-up-the-Engine-development-environment#using-vscode-as-an-ide-for-the-android-embedding-java).
|
||||
For adding IDE support to the Java code in the engine with VSCode, see ["Using VSCode as an IDE for the Android Embedding"](#using-vscode-as-an-ide-for-the-android-embedding-java).
|
||||
|
||||
### Zed Editor
|
||||
|
@ -2,7 +2,7 @@
|
||||
|
||||
Design doc: https://flutter.dev/go/impeller-dart
|
||||
|
||||
Flutter GPU's runtime is a thin wrapper over [Impeller](https://github.com/flutter/flutter/wiki/Impeller)'s HAL, from which custom renderers may be entirely built using Dart. Just like with Impeller, Flutter GPU shader bundles are compiled ahead of time using [impellerc](https://github.com/flutter/engine/tree/main/impeller/compiler). As such, Flutter GPU is only available on platforms that support Impeller.
|
||||
Flutter GPU's runtime is a thin wrapper over [Impeller](README.md)'s HAL, from which custom renderers may be entirely built using Dart. Just like with Impeller, Flutter GPU shader bundles are compiled ahead of time using [impellerc](https://github.com/flutter/engine/tree/main/impeller/compiler). As such, Flutter GPU is only available on platforms that support Impeller.
|
||||
|
||||
## Dart FFI
|
||||
|
||||
@ -45,5 +45,5 @@ If you run into issues while using Flutter GPU, please file a bug using the stan
|
||||
## Questions or feedback?
|
||||
|
||||
If you have non-bug report questions surrounding Flutter GPU, there are several ways you can reach out to the developer:
|
||||
* Create a thread in the #help channel of the [Discord server](https://github.com/flutter/flutter/wiki/Chat). Place "Flutter GPU" in the title of the thread and tag @bdero in the message.
|
||||
* Create a thread in the #help channel of the [Discord server](../../contributing/Chat.md). Place "Flutter GPU" in the title of the thread and tag @bdero in the message.
|
||||
* Send a Twitter DM to [@algebrandon](https://twitter.com/algebrandon).
|
||||
|
@ -2,7 +2,7 @@ We are excited to have you tinker on [the Impeller Scene Demo presented at Flutt
|
||||
|
||||
**Compiling the Engine**
|
||||
|
||||
- Configure your Mac host to compile the Flutter Engine by [following the guidance in wiki](https://github.com/flutter/flutter/wiki/Setting-up-the-Engine-development-environment).
|
||||
- Configure your Mac host to compile the Flutter Engine by [following the guidance in wiki](../contributing/Setting-up-the-Engine-development-environment.md).
|
||||
- Ensure that you are on the [main branch of the Flutter Engine](https://github.com/flutter/engine/tree/main).
|
||||
- Ensure that you are on the [main branch of the Flutter Framework](https://github.com/flutter/flutter/tree/main).
|
||||
- Configure the host build: `./flutter/tools/gn --enable-impeller-3d --no-lto`
|
||||
|
@ -93,7 +93,7 @@ testing/run_tests.py --type=java
|
||||
|
||||
to easily build and run the JUnit tests.
|
||||
|
||||
This script only has a limited amount of smartness. If you've never built the engine before, it'll build the test and classes under test with a reasonable default configuration. If you've built the engine before, it'll re-build the engine with the same GN flags. You may want to double check your GN flags (https://github.com/flutter/flutter/wiki/Compiling-the-engine#compiling-for-android-from-macos-or-linux) if you haven't built the engine for a while.
|
||||
This script only has a limited amount of smartness. If you've never built the engine before, it'll build the test and classes under test with a reasonable default configuration. If you've built the engine before, it'll re-build the engine with the same GN flags. You may want to double check your [GN flags](../contributing/Compiling-the-engine.md#compiling-for-android-from-macos-or-linux) if you haven't built the engine for a while.
|
||||
|
||||
Behind the scenes, it invokes GN and Ninja to build a single .jar file
|
||||
containing the test runner and dependencies. Then it uses the system `java`
|
||||
@ -222,7 +222,7 @@ to easily build and run the XCTests.
|
||||
|
||||
- Add the `--ios-variant ios_debug_sim_unopt_arm64` argument when using an arm64 Mac simulator (built with `--simulator-cpu=arm64`).
|
||||
|
||||
This script only has a limited amount of smartness. If you've never built the engine before, it'll build the test and classes under test with a reasonable default configuration. If you've built the engine before, it'll re-build the engine with the same GN flags. You may want to double check your GN flags (https://github.com/flutter/flutter/wiki/Compiling-the-engine#compiling-for-ios-from-macos) if you haven't built the engine for a while.
|
||||
This script only has a limited amount of smartness. If you've never built the engine before, it'll build the test and classes under test with a reasonable default configuration. If you've built the engine before, it'll re-build the engine with the same GN flags. You may want to double check your GN flags ([See compiling for ios from macos](../contributing/Compiling-the-engine.md#compiling-for-ios-from-macos)) if you haven't built the engine for a while.
|
||||
|
||||
Behind the scenes, it invokes GN and Ninja to build the tests and dependencies
|
||||
into a single `.dylib`. Then it uses Xcode and the Xcode project at
|
||||
@ -329,7 +329,7 @@ Xcode and hit CMD+U.
|
||||
Dart unit tests are executed during pre-submit on our CI system when submitting
|
||||
PRs to the `flutter/engine` repository.
|
||||
|
||||
_See also: [Flutter Test Fonts](https://github.com/flutter/flutter/wiki/Flutter-Test-Fonts)_
|
||||
_See also: [Flutter Test Fonts](../../contributing/testing/Flutter-Test-Fonts.md)_
|
||||
|
||||
### Framework tests
|
||||
|
||||
|
@ -7,6 +7,6 @@ debugging enabled on that device.
|
||||
|
||||
You can also specify a particular Dart file to run if you want to run an example
|
||||
that doesn't have a `lib/main.dart` file using the `-t` command-line option. For
|
||||
example, to run the `widgets/spinning_square.dart` example in the [examples/layers](https://github.com/flutter/flutter/tree/master/examples/layers)
|
||||
example, to run the `widgets/spinning_square.dart` example in the [examples/layers](https://github.com/flutter/flutter/tree/main/examples/layers)
|
||||
directory on a connected Android device, from that directory you would run:
|
||||
`flutter run -t widgets/spinning_square.dart`
|
@ -2,7 +2,7 @@ Several of our dependencies are automatically rolled (updated) by bots.
|
||||
|
||||
## Clang to Engine
|
||||
|
||||
We use an auto-roller for Clang on [Linux](https://autoroll.skia.org/r/clang-linux-flutter-engine) and [MacOS](https://autoroll.skia.org/r/clang-mac-flutter-engine) (Windows is pending availability of a Windows Clang package from the Fuchsia infra team). In case of build failures or other errors, ping the #hackers-engine channel on [Discord](https://github.com/flutter/flutter/wiki/Chat).
|
||||
We use an auto-roller for Clang on [Linux](https://autoroll.skia.org/r/clang-linux-flutter-engine) and [MacOS](https://autoroll.skia.org/r/clang-mac-flutter-engine) (Windows is pending availability of a Windows Clang package from the Fuchsia infra team). In case of build failures or other errors, ping the #hackers-engine channel on [Discord](../contributing/Chat.md).
|
||||
|
||||
These rollers may fail if Clang catches a new compilation warning or error that it previously did not, or if a test relies on undefined behavior that has now changed in the new revision of Clang. It is best to resolve such issues ASAP to let the rollers continue and avoid a pile up of issues to resolve.
|
||||
|
||||
@ -10,7 +10,7 @@ The rollers work by updating a [CIPD](https://chrome-infra-packages.appspot.com/
|
||||
|
||||
## Fuchsia SDK to Engine
|
||||
|
||||
We use an auto-roller for the Fuchsia SDK on [Linux](https://autoroll.skia.org/r/fuchsia-linux-sdk-flutter-engine) and [MacOS](https://autoroll.skia.org/r/fuchsia-mac-sdk-flutter-engine) (Windows is pending availability of a Windows Fuchsia SDK package from the Fuchsia infra team). In case of build failures or other errors, ping the #hackers-engine channel on [Discord](https://github.com/flutter/flutter/wiki/Chat).
|
||||
We use an auto-roller for the Fuchsia SDK on [Linux](https://autoroll.skia.org/r/fuchsia-linux-sdk-flutter-engine) and [MacOS](https://autoroll.skia.org/r/fuchsia-mac-sdk-flutter-engine) (Windows is pending availability of a Windows Fuchsia SDK package from the Fuchsia infra team). In case of build failures or other errors, ping the #hackers-engine channel on [Discord](../contributing/Chat.md).
|
||||
|
||||
These rollers may fail if the Fuchsia SDK contains a breaking change. It is best to resolve such issues ASAP to let the rollers continue and avoid a pile up of issues to resolve.
|
||||
|
||||
@ -33,7 +33,7 @@ The bot updates <https://github.com/flutter/flutter/blob/main/bin/internal/engin
|
||||
|
||||
### Making a breaking change
|
||||
|
||||
Our [breaking change policy](https://github.com/flutter/flutter/wiki/Tree-hygiene#handling-breaking-changes) disallows making changes to the engine that require changes to the framework. If you find the need to do this, you should instead make a soft-breaking change which you can land in multiple phases, as described in that process.
|
||||
Our [breaking change policy](../contributing/Tree-hygiene.md#handling-breaking-changes) disallows making changes to the engine that require changes to the framework. If you find the need to do this, you should instead make a soft-breaking change which you can land in multiple phases, as described in that process.
|
||||
|
||||
### Doing a manual roll
|
||||
|
||||
@ -49,12 +49,12 @@ For example, to generate a description from hash deadbeef to beefdead:
|
||||
$ ./tools/engine_roll_pr_desc.sh deadbeef..beefdead
|
||||
```
|
||||
|
||||
_See also: [Debugging the engine](https://github.com/flutter/flutter/wiki/Debugging-the-engine), which includes instructions on bisecting a roll failure._
|
||||
_See also: [Debugging the engine](../engine/Debugging-the-engine.md), which includes instructions on bisecting a roll failure._
|
||||
|
||||
|
||||
## Dart to Engine
|
||||
|
||||
The Dart SDK is automatically rolled into the engine on a regular basis, following the steps laid out at the [Rolling Dart](https://github.com/flutter/flutter/wiki/Rolling-Dart) page. Since this process is a bit more involved, this autoroller does not use the Skia infrastructure and has a custom dashboard hosted at [go/dart-sdk-roller-dashboard](http://go/dart-sdk-roller-dashboard) (**note: this is likely only accessible from a machine on the Google network**). Using the dashboard, the autoroller can be paused, rolls can be triggered and cancelled, and rolls to a particular revision can be done.
|
||||
The Dart SDK is automatically rolled into the engine on a regular basis, following the steps laid out at the [Rolling Dart](Rolling-Dart.md) page. Since this process is a bit more involved, this autoroller does not use the Skia infrastructure and has a custom dashboard hosted at [go/dart-sdk-roller-dashboard](http://go/dart-sdk-roller-dashboard) (**note: this is likely only accessible from a machine on the Google network**). Using the dashboard, the autoroller can be paused, rolls can be triggered and cancelled, and rolls to a particular revision can be done.
|
||||
|
||||
If there are any issues with this process or the autoroller dashboard, contact bkonyi@ or a member of the Dart VM team.
|
||||
|
||||
|
@ -150,7 +150,7 @@ In order to install the App you will need to:
|
||||
### Adding the Configuration
|
||||
After the app is installed you will need to place a configuration file into your ORGs .github repository. If you do not have one then you will need to create onc in your ORG level .github repository.
|
||||
|
||||
Once the repository is created then you will need to add the Autosubmit configuration file at .github/autosubmit/autosubmit.yml. This is the primary location that Autosubmit will check first for the configuration. Repositories in your ORG can override the ORG level configs by placing a configuration file at repo/.github/autosubmit/autosubmit.yml. See the section on [configuration](https://github.com/flutter/flutter/wiki/Autosubmit-bot#configuration) above on the fields you may want to include in your configuration.
|
||||
Once the repository is created then you will need to add the Autosubmit configuration file at .github/autosubmit/autosubmit.yml. This is the primary location that Autosubmit will check first for the configuration. Repositories in your ORG can override the ORG level configs by placing a configuration file at repo/.github/autosubmit/autosubmit.yml. See the section on [configuration](Autosubmit-bot.md#configuration) above on the fields you may want to include in your configuration.
|
||||
|
||||
Make sure that the App has read write access to the ORG level .github repository.
|
||||
|
||||
|
@ -1,4 +1,4 @@
|
||||
Flutter has installation bundles which you can download and install for the [`beta` channel](https://github.com/flutter/flutter/wiki/Flutter-build-release-channels). (They were previously also available for the `dev` channel, but [the dev channel has been retired](https://medium.com/flutter/whats-new-in-flutter-2-8-d085b763d181#34c4).)
|
||||
Flutter has installation bundles which you can download and install for the [`beta` channel](../releases/Flutter-build-release-channels.md). (They were previously also available for the `dev` channel, but [the dev channel has been retired](https://medium.com/flutter/whats-new-in-flutter-2-8-d085b763d181#34c4).)
|
||||
|
||||
The installation bundles were designed to allow you to have a completely populated environment without having to first download the Git repository, then compile the flutter tool, etc.
|
||||
|
||||
|
@ -17,7 +17,7 @@ diligently check the workflow for any potential security issues.
|
||||
|
||||
## Adding a new GitHub Actions workflow
|
||||
|
||||
To add a new workflow please open a new bug using the [ticket queue process](https://github.com/flutter/flutter/wiki/Infra-Ticket-Queue). The following data points are required:
|
||||
To add a new workflow please open a new bug using the [ticket queue process](Infra-Ticket-Queue.md). The following data points are required:
|
||||
|
||||
* Description/reason to enable this workflow
|
||||
* workflow repository
|
||||
@ -25,7 +25,7 @@ To add a new workflow please open a new bug using the [ticket queue process](htt
|
||||
|
||||
## Updating a GitHub Actions workflow
|
||||
|
||||
To update an existing workflow please open a new bug using the [ticket queue process](https://github.com/flutter/flutter/wiki/Infra-Ticket-Queue). The following data points are required:
|
||||
To update an existing workflow please open a new bug using the [ticket queue process](Infra-Ticket-Queue.md). The following data points are required:
|
||||
|
||||
* Description/reason to update the pinned version
|
||||
* workflow/old_pinned_version
|
||||
|
@ -55,7 +55,7 @@ Quick steps:
|
||||
|
||||
## How to add an integration test as a `Shard` target
|
||||
|
||||
Please refer to [steps-to-add-a-new-framework-test-shard](https://github.com/flutter/flutter/wiki/Adding-a-new-Test-Shard#steps-to-add-a-new-framework-test-shard).
|
||||
Please refer to [steps-to-add-a-new-framework-test-shard](./Adding-a-new-Test-Shard.md#steps-to-add-a-new-framework-test-shard).
|
||||
|
||||
## How to add an integration tests with Android emulator support
|
||||
|
||||
|
@ -14,7 +14,7 @@ This allows the team to separate their engineering work from ["toil" work](https
|
||||
|
||||
IMPORTANT: Whenever you have a request for the infra team, please file a ticket instead of contacting team members directly, even for seemingly trivial things or even if an individual has done the same thing for you in the past. Infra on-call will be there to handle your request, and it lets non on-call team members focus on their engineering tasks.
|
||||
|
||||
When in doubt, ask on the `#hackers-infra` channel in [Chat](https://github.com/flutter/flutter/wiki/Chat).
|
||||
When in doubt, ask on the `#hackers-infra` channel in [Chat](../contributing/Chat.md).
|
||||
|
||||
# How to File a Ticket as an Infra Customer
|
||||
1. Open a [new infra issue](https://github.com/flutter/flutter/issues/new?template=6_infrastructure.yml). (That template summarizes the information on this page.)
|
||||
@ -38,7 +38,7 @@ Below are instructions for infra on-call on how to process the ticket queue. It
|
||||
## Triaging
|
||||
SLO: A ticket in the queue will be triaged within 4 business hours provided it is opened during regularly kept office hours (9 a.m. to 5 p.m. PST). Otherwise it will be triaged the following business day.
|
||||
|
||||
The issue priorities can be found [here](https://github.com/flutter/flutter/wiki/Issue-hygiene#priorities). Issues that are **not P0 or P1** will still be seen (during the infra weekly triage meeting) but do not belong on the ticket queue.
|
||||
The issue priorities can be found [here](../contributing/issue_hygiene/README.md#priorities). Issues that are **not P0 or P1** will still be seen (during the infra weekly triage meeting) but do not belong on the ticket queue.
|
||||
|
||||
New, un-triaged tickets will be in the **New** column in [the ticket queue](https://github.com/orgs/flutter/projects/81/views/1).
|
||||
|
||||
@ -56,7 +56,7 @@ Once all tickets have been triaged, on-call's job is to service them. Apply judg
|
||||
|
||||
From the top of the priority queue down, on-call makes sure that someone is working on each ticket. It's important to keep things moving if you see that they're stuck; try CC'ing people with more information and making it clear what a given ticket is blocked on.
|
||||
|
||||
1. Set the assignee. Read the [guideline](https://github.com/flutter/flutter/wiki/Issue-hygiene#assigning-issues) first. In addition:
|
||||
1. Set the assignee. Read the [guideline](../contributing/issue_hygiene/README.md#assigning-issues) first. In addition:
|
||||
* All tickets must be assigned to someone who is working on them.
|
||||
2. Start working on the ticket
|
||||
* Set the status to "in progress", typically by dragging its card to the **In progress** column.
|
||||
|
@ -6,11 +6,11 @@ This is an index of team-facing documentation for topics relating to Engineering
|
||||
- [Flutter FirebaseLab Tests](Flutter-FirebaseLab-Tests.md)
|
||||
- [Flutter Infrastructure Foundation](Flutter-Infrastructure-Foundation.md)
|
||||
- [Flutter Installation Bundles](Flutter-Installation-Bundles.md)
|
||||
- [Flutter Self Service Index](https://github.com/flutter/flutter/wiki/Flutter-Self-Service-Index)
|
||||
- [Flutter Test Fonts](https://github.com/flutter/flutter/wiki/Flutter-Test-Fonts)
|
||||
- [Flutter Self Service Index](../Flutter-Self-Service-Index.md)
|
||||
- [Flutter Test Fonts](../contributing/testing/Flutter-Test-Fonts.md)
|
||||
- [Flutter's Build Infrastructure](../../dev/bots/README.md)
|
||||
- [Flutter's repository architecture](https://github.com/flutter/flutter/wiki/Flutter%27s-repository-architecture)
|
||||
- [Flutter's repository architecture](../about/Flutter's-repository-architecture.md)
|
||||
- [GitHub Action Workflows](GitHub-Action-Workflows.md)
|
||||
- [Infra Ticket Queue](Infra-Ticket-Queue.md)
|
||||
- [Labeling PRs](../contributing/Labeling-PRs.md)
|
||||
- [New Android Version](https://github.com/flutter/flutter/wiki/New-Android-version)
|
||||
- [New Android Version](../platforms/android/New-Android-version.md)
|
@ -5,7 +5,7 @@ From [Flutter tree dashboard](https://flutter-dashboard.appspot.com/#/build), a
|
||||
|
||||

|
||||
|
||||
* A single run on the same commit and same task, but multiple reruns from test runner. For this case, check logs by clicking `stdout` of the test step: it shows data about failed or succeeded runs in the end ([example](https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket.appspot.com/8841146512187805536/+/u/run_build_aar_module_test/stdout)). See https://github.com/flutter/flutter/wiki/Understanding-a-LUCI-build-failure for how to locate the test step and `stdout`.
|
||||
* A single run on the same commit and same task, but multiple reruns from test runner. For this case, check logs by clicking `stdout` of the test step: it shows data about failed or succeeded runs in the end ([example](https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket.appspot.com/8841146512187805536/+/u/run_build_aar_module_test/stdout)). See [Understanding a LUCI build failure](Understanding-a-LUCI-build-failure.md) for how to locate the test step and `stdout`.
|
||||
|
||||

|
||||
|
||||
|
@ -12,7 +12,7 @@ The Flutter repo does not use a `DEPS` file and `gclient` for its dependencies.
|
||||
|
||||
## Dart Autoroller
|
||||
|
||||
Dart is now automatically rolled into the Flutter engine repository on a regular basis. See [Autorollers](https://github.com/flutter/flutter/wiki/Autorollers) for more information.
|
||||
Dart is now automatically rolled into the Flutter engine repository on a regular basis. See [Autorollers](Autorollers.md) for more information.
|
||||
|
||||
## Using dart_roll_helper.py to roll the version of Dart used by the engine
|
||||
|
||||
@ -51,13 +51,13 @@ If the script completes without errors, move on to step 10 in the next section t
|
||||
## Manually rolling the version of Dart used by the engine
|
||||
|
||||
1. Set up your Engine and Flutter environments by following the instructions described in the pages
|
||||
linked to from [our contributing guide](https://github.com/flutter/engine/blob/master/CONTRIBUTING.md).
|
||||
2. Build the engine according to the instructions on the [[Compiling the engine]] page.
|
||||
3. Select a target Dart revision, typically use the [latest revision](https://github.com/dart-lang/sdk/commits/master). Check that the tests for that revision have all passed (all green) on the [Dart buildbot](https://ci.chromium.org/p/flutter/g/engine/console) and the [Internal Dart Flutter buildbot](https://ci.chromium.org/p/dart/g/flutter/console).
|
||||
4. Create a PR (see [[Tree hygiene]]) that updates `dart_revision` in [DEPS](https://github.com/flutter/engine/blob/master/DEPS) to your selected revision. Invoke `gclient sync` in the src directory to ensure versions corresponding to the DEPS file are synched up.
|
||||
5. Update all Dart-dependent DEPS entries using `engine/src/tools/dart/create_updated_flutter_deps.py` script. In case script complains that dart dependency was removed, remove entry from flutter DEPS file manually. If the list of library source files or patch files is modified, update the file [libraries.yaml](https://github.com/flutter/engine/blob/master/lib/snapshot/libraries.yaml) and regenerate the corresponding json file.
|
||||
linked to from [our contributing guide](../../CONTRIBUTING.md).
|
||||
2. Build the engine according to the instructions on the [Compiling the engine](../engine/contributing/Compiling-the-engine.md) page.
|
||||
3. Select a target Dart revision, typically use the [latest revision](https://github.com/dart-lang/sdk/commits/main). Check that the tests for that revision have all passed (all green) on the [Dart buildbot](https://ci.chromium.org/p/flutter/g/engine/console) and the [Internal Dart Flutter buildbot](https://ci.chromium.org/p/dart/g/flutter/console).
|
||||
4. Create a PR (see [Tree hygiene](../contributing/Tree-hygiene.md)) that updates `dart_revision` in [DEPS](https://github.com/flutter/engine/blob/main/DEPS) to your selected revision. Invoke `gclient sync` in the src directory to ensure versions corresponding to the DEPS file are synched up.
|
||||
5. Update all Dart-dependent DEPS entries using `engine/src/tools/dart/create_updated_flutter_deps.py` script. In case script complains that dart dependency was removed, remove entry from flutter DEPS file manually. If the list of library source files or patch files is modified, update the file [libraries.yaml](https://github.com/flutter/engine/blob/main/lib/snapshot/libraries.yaml) and regenerate the corresponding json file.
|
||||
6. Invoke `gclient sync` in the src directory to ensure versions corresponding to the DEPS file are synched up
|
||||
7. Build the debug, profile, and release versions of the engine, following the normal [[Compiling the engine]] instructions. You will need to build the host versions of the engine too. Here is a script with the build commands:
|
||||
7. Build the debug, profile, and release versions of the engine, following the normal [Compiling the engine](../engine/contributing/Compiling-the-engine.md) instructions. You will need to build the host versions of the engine too. Here is a script with the build commands:
|
||||
|
||||
```bash
|
||||
#!/bin/bash -e
|
||||
@ -75,7 +75,7 @@ cd out
|
||||
find . -mindepth 1 -maxdepth 1 -type d | xargs -n 1 sh -c 'ninja -C $0 -j1000 || exit 255'
|
||||
```
|
||||
|
||||
7. Test the engine version you just built against the top of tree flutter/flutter version using the `--local-engine` and `--local-engine-host` options (see [[The flutter tool]]) against the Flutter Gallery app.
|
||||
7. Test the engine version you just built against the top of tree flutter/flutter version using the `--local-engine` and `--local-engine-host` options (see [The flutter tool](../tool/README.md)) against the Flutter Gallery app.
|
||||
|
||||
```bash
|
||||
cd $FLUTTER_HOME/examples/flutter_gallery
|
||||
@ -91,7 +91,7 @@ cd $FLUTTER_HOME/packages/flutter
|
||||
flutter test --local-engine=host_debug --local-engine-host=host_debug
|
||||
```
|
||||
|
||||
> See [Running a Flutter app with a local engine](https://github.com/flutter/flutter/wiki/Debugging-the-engine#running-a-flutter-app-with-a-local-engine) for more information.
|
||||
> See [Running a Flutter app with a local engine](../engine/Debugging-the-engine.md#running-a-flutter-app-with-a-local-engine) for more information.
|
||||
|
||||
8. Make sure your path contains `engine/src/third_party/dart/tools/sdks/dart-sdk/bin`, run the script `flutter/ci/licenses.sh` in the src directory, update `flutter/ci/licenses_golden/licenses_third_party` by copying `out/license_script_output/licenses_third_party` into it. Include this change in your pull request.
|
||||
**If any licenses changed, make sure to also update the actual `LICENSE` file.**
|
||||
@ -104,6 +104,6 @@ flutter test --local-engine=host_debug --local-engine-host=host_debug
|
||||
|
||||
12. Wait for the [flutter engine build bot](https://ci.chromium.org/p/flutter/g/engine/console) to build your change and go green.
|
||||
|
||||
13. Once the bot cycles green, the [[Autorollers]] will roll the engine into the flutter/flutter repo. When this happens, monitor the flutter [build bots](https://flutter-dashboard.appspot.com/build.html). If there is a failure, revert the Dart roll in flutter/engine, debug the problem and fix it or file a P0 issue against Dart. Please monitor the [flutter benchmarks dashboard](https://flutter-dashboard.appspot.com/benchmarks.html) and if any regressions are noticed please file P0 issues for all regressions **and revert the Dart roll**. The next roll is blocked until these issues/regressions are fixed.
|
||||
13. Once the bot cycles green, the [Autorollers](../infra/Autorollers.md) will roll the engine into the flutter/flutter repo. When this happens, monitor the flutter [build bots](https://flutter-dashboard.appspot.com/build.html). If there is a failure, revert the Dart roll in flutter/engine, debug the problem and fix it or file a P0 issue against Dart. Please monitor the [flutter benchmarks dashboard](https://flutter-dashboard.appspot.com/benchmarks.html) and if any regressions are noticed please file P0 issues for all regressions **and revert the Dart roll**. The next roll is blocked until these issues/regressions are fixed.
|
||||
|
||||
14. When you are done please update the spread sheet at [http://go/dart-flutter-rolls](http://go/dart-flutter-rolls) with the git hash of the Dart revision that was rolled into the flutter engine. This hash will be used for rolling Dart into Google's internal code repository and would be picked as a potential candidate for a dev release. Also make sure you send an email to the next person on the list and make sure the person acknowledges picking up the roll baton.
|
@ -7,7 +7,7 @@ Unopt builds are not published or consumed by the flutter/flutter CI to run inte
|
||||
|
||||
### Sanitizers
|
||||
|
||||
[flutter/engine](https://github.com/flutter/engine) supports thread, address, memory, undefined behavior and leak sanitizers. Sanitizers are not enabled by default but they can be enabled on local builds following the [sanitizers with the flutter engine](https://github.com/flutter/flutter/wiki/Using-Sanitizers-with-the-Flutter-Engine) instructions.
|
||||
[flutter/engine](https://github.com/flutter/engine) supports thread, address, memory, undefined behavior and leak sanitizers. Sanitizers are not enabled by default but they can be enabled on local builds following the [sanitizers with the flutter engine](../engine/Using-Sanitizers-with-the-Flutter-Engine.md) instructions.
|
||||
|
||||
### Builds with sanitizers, and tests with assertions enabled
|
||||
|
||||
|
@ -25,15 +25,15 @@ An example build: [Linux color_filter_and_fade_perf__e2e_summary](https://ci.chr
|
||||
1. Check if the infra failure has happened on earlier builds by clicking (i)
|
||||
2. Check if issue already exists in the [infra bug pool](https://github.com/flutter/flutter/issues?q=is%3Aopen+is%3Aissue+label%3A%22team%3A+infra%22)
|
||||
3. If not, file [an infra bug](https://github.com/flutter/flutter/issues/new?template=6_infrastructure.yml)
|
||||
4. If this is a blocking failure, please add Projects [`Infra Ticket Queue`](https://github.com/flutter/flutter/wiki/Infra-Ticket-Queue). The infra gardener will scan through the queue frequently.
|
||||
4. If this is a blocking failure, please add Projects [`Infra Ticket Queue`](./Infra-Ticket-Queue.md). The infra gardener will scan through the queue frequently.
|
||||
5. If you want to get an immediate help, please ask in the discord `hackers-infra` channel
|
||||
6. If this is an infra flake, and a retry is needed
|
||||
* For pre-submit test, click `Re-run` in the [check run page](https://github.com/flutter/flutter/pull/83894/checks?check_run_id=2738146673). 
|
||||
* Limited to `flutter-hackers` group.
|
||||
* Ask a team member to re-run in [Chat](https://github.com/flutter/flutter/wiki/Chat) channel `#hackers-infra` if you don't have access.
|
||||
* Ask a team member to re-run in [Chat](../contributing/Chat.md) channel `#hackers-infra` if you don't have access.
|
||||
* For post-submit test, login to [framework build dashboard](https://flutter-dashboard.appspot.com/#/build), click the task box, and click `RERUN`. 
|
||||
* Limited to Googlers currently due to some technical limitations of our infrastructure.
|
||||
* Ask a Googler to re-run in [Chat](https://github.com/flutter/flutter/wiki/Chat) channel `#hackers-infra`.
|
||||
* Ask a Googler to re-run in [Chat](../contributing/Chat.md) channel `#hackers-infra`.
|
||||
|
||||
## Test Failure
|
||||
A test failure shows up as a red box in the dashboards:
|
||||
|
@ -14,7 +14,7 @@ You can then re-run `flutter update-packages --force-upgrade`.
|
||||
|
||||
## To update a single dependency for cherrypicks:
|
||||
|
||||
Sometimes you need to update a single dependency as a [cherrypick to a release candidate branch](https://github.com/flutter/flutter/wiki/Flutter-Cherrypick-Process).
|
||||
Sometimes you need to update a single dependency as a [cherrypick to a release candidate branch](../releases/Flutter-Cherrypick-Process.md).
|
||||
|
||||
In that case, you can run:
|
||||
|
||||
|
@ -3,9 +3,9 @@ Hybrid composition refers to the ability of composing native views alongside Flu
|
||||
## Android
|
||||
*Requires API level 19*
|
||||
|
||||
_See also: [[Texture Layer Hybrid Composition]]_
|
||||
_See also: [Texture Layer Hybrid Composition](./android/Texture-Layer-Hybrid-Composition.md)_
|
||||
|
||||
Starting from Flutter 1.20.0, hybrid composition can be used on Android. This new feature fixes most of the [issues with the preview platform view approach](https://github.com/flutter/flutter/wiki/Virtual-Display#associated-problems-and-workarounds) (Virtual Display); in particular, accessibility and keyboard related issues. See also [[Android Platform Views]] for an overview of modes.
|
||||
Starting from Flutter 1.20.0, hybrid composition can be used on Android. This new feature fixes most of the [issues with the preview platform view approach](./android/Virtual-Display.md#associated-problems-and-workarounds) (Virtual Display); in particular, accessibility and keyboard related issues. See also [Android Platform Views](./android/Android-Platform-Views.md) for an overview of modes.
|
||||
|
||||
To see all known issues specific to this mode, search for the [`hc-only` label](https://github.com/flutter/flutter/labels/hc-only).
|
||||
|
||||
@ -186,8 +186,6 @@ android {
|
||||
```
|
||||
## iOS
|
||||
|
||||
_See also: [[Hybrid Composition iOS]]_
|
||||
|
||||
In Flutter 1.22, platform views are enabled by default. This means
|
||||
that it's no longer required to add the
|
||||
`io.flutter.embedded_views_preview` flag to `Info.plist`.
|
@ -30,7 +30,7 @@ within their Flutter UI.
|
||||
|
||||
There are currently three different implementations of Android platform views:
|
||||
- [Virtual Display](Virtual_Display.md) (VD)
|
||||
- [Hybrid Composition](https://github.com/flutter/flutter/wiki/Hybrid-Composition) (HC)
|
||||
- [Hybrid Composition](../Hybrid-Composition.md) (HC)
|
||||
- [Texture Layer Hybrid Composition](Texture-Layer-Hybrid-Composition.md) (TLHC)
|
||||
|
||||
Each has a different set of limitations and tradeoffs, as discussed below. The pages linked above give details about each implementation.
|
||||
|
@ -40,7 +40,7 @@ https://docs.flutter.dev/reference/supported-platforms
|
||||
#### Modify defaults
|
||||
In flutter/flutter:
|
||||
Update default compile sdk version and target sdk version to the new api value
|
||||
Code here https://github.com/flutter/flutter/blob/master/packages/flutter_tools/gradle/src/main/groovy/flutter.groovy
|
||||
[Code here](../../../packages/flutter_tools/gradle/src/main/groovy/flutter.groovy)
|
||||
Follow comments in that file to update other locations that are assumed to be the same.
|
||||
Example bumping min sdk which is similar but different: https://github.com/flutter/flutter/pull/125515
|
||||
In flutter/buildroot:
|
@ -1,4 +1,4 @@
|
||||
_See also: [Hybrid Composition|Hybrid Composition#Android](https://github.com/flutter/flutter/wiki/Hybrid-Composition)_
|
||||
_See also: [Hybrid Composition|Hybrid Composition#Android](../Hybrid-Composition.md)_
|
||||
|
||||
# Background
|
||||
|
||||
|
@ -6,7 +6,7 @@ Prior to [Pull Request 7902](https://github.com/flutter/flutter/pull/7902) -- wh
|
||||
|
||||
If you have a project that was created prior to this date, please follow these steps to switch to building with gradle. This is required as we will be removing the custom build support shortly.
|
||||
|
||||
*Note*: These steps apply to projects created with `flutter create` prior to February 6th 2017. If your project was based on a copy of `/examples/hello_services/`, then you just need to synchronize the contents of [`/android/build.gradle`](https://github.com/flutter/flutter/blob/master/packages/flutter_tools/templates/create/android.tmpl/build.gradle) and [`/android/app/build.gradle`](https://github.com/flutter/flutter/blob/master/packages/flutter_tools/templates/create/android.tmpl/app/build.gradle).
|
||||
*Note*: These steps apply to projects created with `flutter create` prior to February 6th 2017. If your project was based on a copy of `/examples/hello_services/`, then you just need to synchronize the contents of [`/android/build.gradle`](../../../packages/flutter_tools/templates/create/android.tmpl/build.gradle) and [`/android/app/build.gradle`](../../../packages/flutter_tools/templates/create/android.tmpl/app/build.gradle).
|
||||
|
||||
## Upgrading an existing project
|
||||
|
@ -29,4 +29,4 @@ We also plan to offer support for compilation directly to ARM64, as well as univ
|
||||
|
||||
## Filing Issues
|
||||
|
||||
If you experience a problem relating to using Flutter on Apple Silicon hardware, please [file an issue on GitHub](https://github.com/flutter/flutter/issues/new?assignees=&labels=&template=1_activation.md&title=) with specific repro steps and information about your hardware and software configuration (paste the results of `flutter doctor -v`). Thank you!
|
||||
If you experience a problem relating to using Flutter on Apple Silicon hardware, please [file an issue on GitHub](https://github.com/flutter/flutter/issues/new?template=1_activation.yml) with specific repro steps and information about your hardware and software configuration (paste the results of `flutter doctor -v`). Thank you!
|
@ -32,7 +32,7 @@ Anyone can request a cherry-pick.
|
||||
### When do I request a cherry pick?
|
||||
|
||||
- Whenever you have identified a commit on the main/master that fixes an issue that is present on the beta or stable branch.
|
||||
- Whenever you need to update a pub dependency that fixes an issue that is present on the beta or stable branch (see [Updating dependencies](https://github.com/flutter/flutter/wiki/Updating-dependencies-in-Flutter#to-update-a-single-dependency-for-cherrypicks))
|
||||
- Whenever you need to update a pub dependency that fixes an issue that is present on the beta or stable branch (see [Updating dependencies](../infra/Updating-dependencies-in-Flutter.md#to-update-a-single-dependency-for-cherrypicks)
|
||||
|
||||
### Who reviews and approves cherry-pick requests?
|
||||
|
||||
|
@ -5,7 +5,7 @@ Flutter has the following channels, in increasing order of stability.
|
||||
### `master` (aka `main`)
|
||||
|
||||
The current tip-of-tree, absolute latest cutting edge build. Usually functional, though sometimes we accidentally break things. We do not run the entirety of our testing before allowing patches to land on this branch. We do not
|
||||
recommend using this branch unless [you are contributing to Flutter](https://github.com/flutter/flutter/blob/main/CONTRIBUTING.md).
|
||||
recommend using this branch unless [you are contributing to Flutter](../../CONTRIBUTING.md).
|
||||
|
||||
The API documentation for the most recent commit on `master` is staged at: <https://master-api.flutter.dev>
|
||||
|
||||
@ -17,7 +17,7 @@ _We are planning to rename this channel to `main` soon; this work is tracked in
|
||||
|
||||
The latest stable release. If you want to be using the latest and greatest, the `beta` branch is the right choice. That's the most recent version of Flutter that we have heavily tested. The beta branch has passed all our public testing, has been verified against test suites for Google products that use Flutter, and has been vetted against [contributed private test suites](https://github.com/flutter/tests).
|
||||
|
||||
We branch from `master` for a new beta release at the beginning of the month, usually the first Wednesday. This includes a branch for Dart, the engine and the framework. These branches are then "stabilized" for the next couple of weeks, meaning we accept [cherrypick](https://github.com/flutter/flutter/wiki/Flutter-Cherrypick-Process) requests for high impact issues. Once a quarter, the beta branch lives on to become the next stable branch, as detailed below.
|
||||
We branch from `master` for a new beta release at the beginning of the month, usually the first Wednesday. This includes a branch for Dart, the engine and the framework. These branches are then "stabilized" for the next couple of weeks, meaning we accept [cherrypick](Flutter-Cherrypick-Process.md) requests for high impact issues. Once a quarter, the beta branch lives on to become the next stable branch, as detailed below.
|
||||
|
||||
On average it takes about two weeks for a fix to end up in the beta branch after it lands in our repository (in the `master` channel).
|
||||
|
||||
@ -29,7 +29,7 @@ Roughly speaking, every third `beta` is promoted to `stable`. This is essentiall
|
||||
|
||||
We recommend using this channel for new users and for production app releases.
|
||||
|
||||
In case of high severity, high impact or security issues, we may do a hotfix release for the `stable` channel just like we do for `beta`. This will follow the same [cherrypick](https://github.com/flutter/flutter/wiki/Flutter-Cherrypick-Process) process.
|
||||
In case of high severity, high impact or security issues, we may do a hotfix release for the `stable` channel just like we do for `beta`. This will follow the same [cherrypick](Flutter-Cherrypick-Process.md) process.
|
||||
|
||||
The `stable` version of Flutter is the one documented by our API documentation at: <https://api.flutter.dev>
|
||||
|
||||
@ -52,12 +52,12 @@ To switch channels, run `flutter channel [<channel-name>]`, and then run `flutte
|
||||
|
||||
## Will a particular bug fix be provided in a hotfix release?
|
||||
|
||||
Depending on the severity of the issue, it is possible. Refer to the [cherrypick process](https://github.com/flutter/flutter/wiki/Flutter-Cherrypick-Process) for details.
|
||||
Depending on the severity of the issue, it is possible. Refer to the [cherrypick process](Flutter-Cherrypick-Process.md) for details.
|
||||
|
||||
If you really need a particular patch and it's a fix to the flutter/flutter repository, you should feel free to create a Flutter branch yourself on your development machine and cherry-pick the fix you want onto that branch. Flutter is distributed as a `git` repository and all of `git`'s tools are available to you. If you need a particular patch that's from the flutter/engine repository or one of our dependencies (e.g. Dart or Skia), you could build your own engine but it's probably easier to just wait until the next release. On average, the next `beta` release is about two weeks away.
|
||||
|
||||
## See also
|
||||
|
||||
* [Release process](Release-process.md), which describes the details for how we push builds from channel to channel.
|
||||
* [Cherrypick process](https://github.com/flutter/flutter/wiki/Flutter-Cherrypick-Process), where we cover how to request an issue for cherrypicking.
|
||||
* [Cherrypick process](Flutter-Cherrypick-Process.md), where we cover how to request an issue for cherrypicking.
|
||||
* [Release notes](https://flutter.dev/docs/development/tools/sdk/release-notes), where we document changes to each version of the stable channel.
|
||||
|
@ -20,7 +20,7 @@ without them needing to read each issue individually.
|
||||
Our goal is to make the list easy for them to scan.
|
||||
|
||||
More information and tips:
|
||||
https://github.com/flutter/flutter/wiki/Hotfix-Documentation-Best-Practices
|
||||
docs/releases/Hotfix-Documentation-Best-Practices.md
|
||||
|
||||
INTERNAL NOTE
|
||||
-->
|
||||
|
@ -2,7 +2,7 @@ With each beta we need to test that there are no regressions. We have lots of au
|
||||
|
||||
## When to test betas
|
||||
|
||||
We announce betas on our Discord (see the [Chat](https://github.com/flutter/flutter/wiki/Chat) page for the invite link), in the #releases channel, about once a month.
|
||||
We announce betas on our Discord (see the [Chat](../contributing/Chat.md) page for the invite link), in the #releases channel, about once a month.
|
||||
|
||||
## How to get a beta build
|
||||
|
||||
|
@ -2,7 +2,7 @@ In the interest of transparency, we want to share high-level details of our road
|
||||
|
||||
Our plans will evolve over time based on customer feedback and new market opportunities. We use our quarterly surveys and feedback on GitHub issues to prioritize work. The list here shouldn't be viewed either as exhaustive, nor a promise that we will complete all this work. If you have feedback about what you think we should be working on, we encourage you to get in touch (e.g. by [filing an issue](https://github.com/flutter/flutter/issues/new/choose), or using the "thumbs-up" emoji reaction on an issue's first comment). Flutter is an open source project, we invite contributions both towards the themes presented below and in other areas.
|
||||
|
||||
_If you are a contributor or team of contributors with long-term plans for [contributing to Flutter](https://github.com/flutter/flutter/blob/master/CONTRIBUTING.md), and would like your planned efforts reflected in the roadmap, please reach out to Hixie (ian@hixie.ch)._
|
||||
_If you are a contributor or team of contributors with long-term plans for [contributing to Flutter](../../CONTRIBUTING.md), and would like your planned efforts reflected in the roadmap, please reach out to Hixie (ian@hixie.ch)._
|
||||
|
||||
# 2024
|
||||
|
||||
@ -76,4 +76,4 @@ We're still not planning on investing in built-in support for [code push or hot
|
||||
|
||||
***
|
||||
|
||||
_We maintain an [archive of roadmaps from previous years](https://github.com/flutter/flutter/wiki/%5BArchive%5D-Old-Roadmaps) in a separate page._
|
||||
_We maintain an [archive of roadmaps from previous years]([Archive]-Old-Roadmaps.md) in a separate page._
|
@ -71,7 +71,7 @@ We unfortunately have had to shelve our current efforts to implement hot reload
|
||||
|
||||
In general we prioritize [issues with the most thumbs-up reactions on GitHub](https://github.com/flutter/flutter/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc), and the astute among you may notice that the list of non-goals includes a number of these highest-rated issues. Unfortunately, we have discovered a pattern that we did not expect, though it is obvious in retrospect: when we address all the highest-ranked issues except for those that are technically infeasible or intractable for whatever reason, the result is that the highest-ranked issues that are left are _all_ issues that are infeasible or somehow intractable.
|
||||
|
||||
_See also: [[Popular issues]], which discusses each of the top 10 issues._
|
||||
_See also: [Popular issues](../contributing/issue_hygiene/Popular-issues.md), which discusses each of the top 10 issues._
|
||||
|
||||
|
||||
# 2022
|
||||
@ -172,7 +172,7 @@ While in 2020 we primarily focused on fixing bugs, in 2021 we plan to also add s
|
||||
|
||||
## Release Channels and Cadence
|
||||
|
||||
Flutter offers three “channels” from which developers can receive updates: master, beta and stable, with increasing levels of stability and confidence of quality but longer lead times for changes to propagate. We plan to release one beta build each month, typically near the start of the month, and about four stable releases throughout the year. We recommend that you use the stable channel for apps released to end-users. For more details on our release process, see the [Flutter build release channels](https://github.com/flutter/flutter/wiki/Flutter-build-release-channels) wiki page.
|
||||
Flutter offers three “channels” from which developers can receive updates: master, beta and stable, with increasing levels of stability and confidence of quality but longer lead times for changes to propagate. We plan to release one beta build each month, typically near the start of the month, and about four stable releases throughout the year. We recommend that you use the stable channel for apps released to end-users. For more details on our release process, see the [Flutter build release channels](../releases/Flutter-build-release-channels.md) wiki page.
|
||||
|
||||
We used to also have a _dev_ channel which represented a level of stability between master and beta. At the end of 2021, we retired this channel; it is no longer updated.
|
||||
|
||||
@ -198,4 +198,4 @@ We intend to deliver on long-anticipated features such as our router refactor, i
|
||||
|
||||
In general in 2020 we intend to primarily focus on fixing bugs rather than adding new features.
|
||||
|
||||
_We mainly use the "Thumbs-Up" emoji reactions on the first comment of an issue to determine its importance. See the [Issue hygiene](https://github.com/flutter/flutter/wiki/Issue-hygiene) wiki page for more details on our prioritization strategy._
|
||||
_We mainly use the "Thumbs-Up" emoji reactions on the first comment of an issue to determine its importance. See the [Issue hygiene](../contributing/issue_hygiene/README.md) wiki page for more details on our prioritization strategy._
|
@ -2,7 +2,7 @@
|
||||
|
||||
The process of triaging new incoming bugs consiists of processing the list of [issues without team-* labels, with no assignees, and not labeled `will need additional triage`](https://github.com/flutter/flutter/issues?q=is%3Aissue+is%3Aopen+no%3Aassignee+-label%3A%22will+need+additional+triage%22+-label%3Ateam-release%2Cteam-codelabs%2Cteam-ecosystem%2Cteam-infra%2Cteam-engine%2Cteam-framework%2Cteam-news%2Cteam-ios%2Cteam-tool%2Cteam-web%2Cteam-desktop%2Cteam-design%2Cteam-android%2Cteam-go_router%2Cteam-games%2Cteam-text-input+) as described in this section, so as to make that list empty.
|
||||
|
||||
_See also: [[Issue triage reports]]_
|
||||
_See also: [Issue triage reports](../wiki_archive/Nevercode%20[TBD]/Issue-triage-reports.md)_
|
||||
|
||||
### General
|
||||
|
||||
@ -22,7 +22,7 @@ Ideally every issue would have a sample app that demonstrated the problem.
|
||||
|
||||
Performance bugs should have timeline traces.
|
||||
|
||||
Crashes should have crash logs with a Flutter version so that the [flutter-symbolizer-bot](https://github.com/flutter-symbolizer-bot) can do its work (see also [[Crashes]]).
|
||||
Crashes should have crash logs with a Flutter version so that the [flutter-symbolizer-bot](https://github.com/flutter-symbolizer-bot) can do its work (see also [Crashes](../engine/Crashes.md)).
|
||||
|
||||
#### What makes an issue actionable
|
||||
|
||||
@ -60,7 +60,7 @@ Some labels are used to track the flow of issues from the time they're filed unt
|
||||
* `assigned for triage`: The issue is assigned to a domain expert for further triage.
|
||||
* `has reproducible steps`: The issue has a reproducible case or test, Flutter doctor output, and usable stack traces if appropriate. It is actionable in the sense that it can be routed to a domain team for action.
|
||||
* `needs repro info`: We need more reproduction steps in order to be able to act on this issue.
|
||||
* `workaround available`: A workaround is available to overcome the issue until it is properly addressed. Read more about [providing workarounds](https://github.com/flutter/flutter/wiki/Issue-hygiene#comments-providing-workarounds).
|
||||
* `workaround available`: A workaround is available to overcome the issue until it is properly addressed. Read more about [providing workarounds](../contributing/issue_hygiene/README.md#comments-providing-workarounds).
|
||||
* `will need additional triage`: Assign this if you don't know how to route it to a team.
|
||||
|
||||
**To complete the triage of an issue, add one (and only one) `team-*` label**. Team labels differ from the similar category names (such as `engine` or `framework`) in that the category labels indicate what part(s) of the codebase an issue affects, while `team-*` labels indicate the team that owns that work. Most issues will have both, and they won't always match.
|
||||
@ -124,7 +124,7 @@ Each team has an **incoming issue list**, the issues assigned to that team (team
|
||||
|
||||
Each issue in this list should be examined, cleaned up (see next section), and either:
|
||||
- closed, with a comment saying why (e.g. is a duplicate, is not actionable, is invalid). The [`r:`](https://github.com/flutter/flutter/labels?q=r%3A) labels may be of use when closing an issue.
|
||||
- given a [priority](https://github.com/flutter/flutter/wiki/Issue-hygiene#priorities), and tagged with the team's corresponding `triaged-*` label. This marks the issue as triaged. If the priority is P3 and the reporter has expressed that the issue is important to them, it will help the reporter feel welcome if a comment is added expressing empathy for their plight and explaining why it is not something we consider important.
|
||||
- given a [priority](../contributing/issue_hygiene/README.md#priorities), and tagged with the team's corresponding `triaged-*` label. This marks the issue as triaged. If the priority is P3 and the reporter has expressed that the issue is important to them, it will help the reporter feel welcome if a comment is added expressing empathy for their plight and explaining why it is not something we consider important.
|
||||
- sent to another team, by removing the current `team-*` label and adding another one. A comment should be added explaining the action.
|
||||
- sent back to primary triage, by removing the `team-*` label but not adding another one. A comment should be added explaining the action.
|
||||
- escalated to critical triage, by adding the `will need additional triage` label. A comment should be added explaining the action.
|
||||
@ -190,7 +190,7 @@ Teams should also go through all PRs in their area (ideally in a separate meetin
|
||||
2. Check that the assigned reviewers have left comments; if not, contact them to remind them.
|
||||
3. Check that any questions on the PR from the contributor have been answered.
|
||||
|
||||
For more guidance on reviewing PRs, see [Tree Hygiene](https://github.com/flutter/flutter/wiki/Tree-hygiene#how).
|
||||
For more guidance on reviewing PRs, see [Tree Hygiene](../contributing/Tree-hygiene.md#how).
|
||||
|
||||
## Links for teams
|
||||
|
||||
@ -303,7 +303,7 @@ PRs are reviewed weekly across the framework, packages, and engine repositories:
|
||||
|
||||
### Web platform team (`team-web`)
|
||||
|
||||
- See the [Flutter Web Triage](https://github.com/flutter/flutter/wiki/Flutter-Web-Triage) page.
|
||||
- See the [Flutter Web Triage](Flutter-Web-Triage.md) page.
|
||||
|
||||
## Adding a new team
|
||||
|
@ -1,3 +0,0 @@
|
||||
## Moved
|
||||
|
||||
Add-to-app is now released with Flutter v1.12. The updated documentations are at [https://flutter.dev/docs/development/add-to-app/](https://flutter.dev/docs/development/add-to-app/)
|
@ -1 +0,0 @@
|
||||
Please see [Binding to native code using dart:ffi](https://flutter.dev/docs/development/platform-integration/c-interop) on [flutter.dev](https://flutter.dev/)
|
@ -1,5 +0,0 @@
|
||||
Flutter previously supported code generation via `flutter generate`.
|
||||
|
||||
However, `flutter generate` is deprecated and slated to be removed in a future flutter release. Instead, consider `build runner`, which is easier to use directly, and can be used to generate code for Flutter projects.
|
||||
|
||||
_See also: https://pub.dev/packages/build_runner_
|
@ -1,29 +0,0 @@
|
||||
The Flutter team currently maintains the following codelabs:
|
||||
|
||||
* [Write Your First Flutter App, part 1](https://codelabs.developers.google.com/codelabs/first-flutter-app-pt1/#0)
|
||||
* Create a simple mobile app that generates proposed names for a startup company. In part one, you’ll use a package that returns pairs of words at random and inserts them into an infinite scrolling list.
|
||||
* [Write Your First Flutter App, part 2](https://codelabs.developers.google.com/codelabs/first-flutter-app-pt2/#0)
|
||||
* Create a simple mobile app that generates proposed names for a startup company. In part two, you’ll extend the example from part 1 to allow the user to select favorite word pairs, and add a second “Saved Favorites” page where users can view the selected names. Finally, you’ll change the app’s theme color.
|
||||
* [Basic Flutter layout](https://flutter.dev/docs/codelabs/layout-basics)
|
||||
* Use DartPad in a browser (no need to download Flutter or Dart!) to learn the basics of creating a Flutter layout.
|
||||
* [Building Beautiful UIs with Flutter](https://codelabs.developers.google.com/codelabs/flutter/#0)
|
||||
* A deeper “first dive” than “Write Your First Flutter App.” In this codelab you’ll create a chat app that includes a simple animation, and customizes the UI for iOS and Android.
|
||||
* [Adding Google Maps to a Flutter App](https://codelabs.developers.google.com/codelabs/google-maps-in-flutter/#0)
|
||||
* Display a Google map in an app, retrieve data from a web service, and display the data as markers on the map.
|
||||
* [Build a Photo Sharing App with Google Photos and Flutter](https://codelabs.developers.google.com/codelabs/google-photos-sharing/#0)
|
||||
* Build a field trip app that allows you and other members of the trip to share photos.
|
||||
* [Building a Cupertino app with Flutter](https://codelabs.developers.google.com/codelabs/flutter-cupertino/#0)
|
||||
* Build a version of the Shrine shopping app (used in the Material Design codelabs) using the Cupertino package to create an iOS style look and feel. Create multiple tabs and navigate between them.
|
||||
* [Firebase for Flutter](https://codelabs.developers.google.com/codelabs/flutter-firebase/#0)
|
||||
* Connect a Flutter app to a Firebase database, and use a transaction to update shared information.
|
||||
* [MDC 101 Flutter: Material Components (MDC) Basics](https://codelabs.developers.google.com/codelabs/mdc-101-flutter/#0)
|
||||
* Learn the basics of using Material Components by building a simple app with core components. The four MDC codelabs guide you through building an e-commerce app called Shrine. You’ll start by building a login page using several of MDC Flutter’s components.
|
||||
* [MDC 102 Flutter: Material Structure and Layout](https://codelabs.developers.google.com/codelabs/mdc-102-flutter/#0)
|
||||
* Learn how to use Material for structure and layout in Flutter. Continue building the e-commerce app, introduced in MDC-101, by adding navigation, structure, and data.
|
||||
* [MDC 103 Flutter: Material Theming with Color, Shape, Elevation, and Type](https://codelabs.developers.google.com/codelabs/mdc-103-flutter/#0)
|
||||
* Discover how Material Components for Flutter make it easy to differentiate your product, and express your brand through design. Continue building your e-commerce app by adding a home screen that displays products.
|
||||
* [MDC 104 Flutter: Material Advanced Components](https://codelabs.developers.google.com/codelabs/mdc-104-flutter/#0)
|
||||
* Improve your design and learn to use our advanced component backdrop menu. Finish your e-commerce app by adding a backdrop with a menu that filters products by the selected category.
|
||||
|
||||
|
||||
If you find errors with the codelabs, please create [issues](https://github.com/flutter/flutter/issues) with the [dev: docs - codelab](https://github.com/flutter/flutter/labels/dev%3A%20docs%20-%20codelab) and [TODAY](https://github.com/flutter/flutter/labels/%E2%9A%A0%20TODAY) labels.
|
@ -1,305 +0,0 @@
|
||||
# Deferred Components
|
||||
|
||||
Deferred components is a set of features and tooling that allows developers to write dart code that can be AOT compiled into separate split dynamic libraries as well as package them together with assets into runtime downloadable modules on Android. The primary goal of deferred components is to reduce install apk size as well as reduce storage space taken up by the app by omitting features the user may not use.
|
||||
|
||||
This feature is currently an experimental/preview feature that is only available on Android. It takes advantage of Android and Google Play Store’s dynamic feature modules to deliver the deferred components packaged as Android modules. This does not impact other platforms, which continue to build as normal with all deferred components and assets included at initial install time.
|
||||
|
||||
Though modules can be defer loaded, the entire application must be completely built and uploaded as a single Android App Bundle (`.aab`). Dispatching partial updates without re-uploading new Android App Bundles for the entire application (eg, code push) is not supported.
|
||||
|
||||
This feature only does deferred loading in release and profile mode. In debug mode, all deferred components are present at launch and will instantly load.
|
||||
|
||||
A step by step guide on how to integrate deferred components with your app can be found on the [Flutter.dev documentation](https://flutter.dev/docs/perf/deferred-components).
|
||||
|
||||
## APK size gallery case study
|
||||
|
||||
Flutter Gallery implements deferred components for the crane study. Here, we will examine the initial install size gains in a [fully deferred Flutter gallery branch](https://github.com/flutter/gallery/tree/fully-deferred-gallery) (branch not kept up to date with master) where we implement deferred components for all studies and demos (not just crane). In this example, we have moved all the splittable assets and fonts into deferred components. Compared to a non-deferred components application, the initial installed APK file size breakdown is as follows:
|
||||
|
||||
Deferred components:
|
||||
|
||||
* base-arm64_v8a.apk - 12,325,372 bytes
|
||||
* base-master.apk - 37,889,309 bytes
|
||||
* Total deferred components initial installation size: 50,214,681 bytes
|
||||
|
||||
Non-deferred components (regular app):
|
||||
|
||||
* base-arm64_v8a.apk - 12,521,900 bytes
|
||||
* base-master.apk - 80,605,796 bytes
|
||||
* Total regular initial installation size: 93,127,696 bytes
|
||||
|
||||
Here, we can see a ~200kB decrease in compiled dart code size (base-arm64_v8a.apk) and a ~43mB decrease in assets (base-master.apk) on initial download. Overall, there is a 46% reduction in initial installation size. The dart code, assets, and google fonts are instead moved into separate components downloaded at runtime only when needed:
|
||||
|
||||
* Crane
|
||||
* Fortnightly
|
||||
* Rally
|
||||
* Shrine
|
||||
* Cupertino
|
||||
* Material
|
||||
* Reference
|
||||
|
||||
The total installed size with all components installed is slightly larger than the non-deferred app, but this increase is on the order of a few kb due to overhead in the dart shared libraries from ELF headers and cross-loading-unit calls.
|
||||
|
||||
## Deferred components app structure
|
||||
|
||||
The deferred Dart libraries are interpreted by `gen_snapshot` (Dart’s compiler) to produce “loading units”, each of which are output as a split AOT shared library (`.so` file) when building in profile or release mode. A loading unit is the smallest set of libraries that are imported exclusively with the deferred keyword by the main code and can be split off of the base libraries.
|
||||
|
||||
The following diagram shows an example app structure and a “lifecycle” of how deferred dart libraries are compiled into loading units and packaged into a `.aab` file.
|
||||
|
||||

|
||||
|
||||
This example app has the following properties:
|
||||
|
||||
* Four Dart libraries, with Dart libraries `lib1` and `lib2` dependent on each other. `lib1`, `lib3`, and `lib4` are imported in the flutter app’s main code as deferred.
|
||||
* Four loading units, with one being the base loading unit with id 1 and loading unit 2 containing both `lib1` and `lib2`. Loading units 3 and 4 contain `lib3` and `lib4` respectively.
|
||||
* Three defined deferred components, plus an implicit base component. `component1` contains loading unit 2 and assets. `component2` contains both loading units 3 and 4 and no assets. `component3` is an assets only component.
|
||||
* `app-release.aab` is the completed build output file, and contains all three components as well as the base component.
|
||||
|
||||
There will always be an implicit base loading unit that contains core flutter packages as well as your base application code. Any libraries that are not fully imported as deferred by your base app code will be included in the base loading unit. If no additional loading units other than base are generated, it likely means you imported your files incorrectly.
|
||||
|
||||
Multiple Dart libraries are compiled as a single loading unit if they import each other eagerly (non-deferred):
|
||||
|
||||

|
||||
|
||||
## Lifecycle of a `loadLibrary()` call
|
||||
|
||||
Deferred components are primarily triggered to be downloaded, installed, and loaded via the `loadLibrary()` dart call. This call is handled differently in dart2js vs aot/native. Here, we will trace how the `loadLibrary()` call is translated into an installation of a deferred component:
|
||||
|
||||

|
||||
|
||||
The `loadLibrary()` dart call's native side implementation calls a `Dart_DeferredLoadHandler` callback that is set using `Dart_SetDeferredLoadHandler` in `DartIsolate::Initialize`. Dart internally retrieves the loading unit ID assigned to the library and passes it to the callback. The callback is implemented as `DartIsolate::OnDartLoadLibrary`.
|
||||
|
||||
The loading unit ID is then passed on through the runtime controller, engine shell and platform view until it passes into the FlutterJNI in the Android embedder. Here, the loading unit ID is passed into the `DeferredComponentsManager`'s `installDeferredComponent` where the ID is converted from an integer to a String name identifying the pubspec-defined deferred component the requested library belongs to. This conversion is handled by a AndroidManifest metadata mapping that is created and verified during the build phase.
|
||||
|
||||
`PlayStoreDeferredComponentManager` then invokes the play store split compat APIs to download the android module. Once the Android module is installed, the manager locates the .so files and passes the paths to the engine to `dlopen`. The engine then passes the symbols to the runtime and and dart isolate, which is able to load the symbols into the dart VM. The loading must be associated with a loading unit ID or the load will not complete the Dart Future returned by `loadLibrary()`.
|
||||
|
||||
Keep in mind that multiple loading units may be contained in a deferred component, but a `loadLibrary` call will only load the dart symbols from the specific dart library the call was made from. Each loading unit must have separate `loadLibrary` calls before use. Subsequent `loadLibrary` calls on components that are already downloaded should complete much faster, however, the loading can never happen synchronously and there will be at least one frame between call and completion.
|
||||
|
||||
### Installation by deferred component string name
|
||||
|
||||
We also provide a [framework-side DeferredComponent utility class](https://master-api.flutter.dev/flutter/services/DeferredComponent-class.html) that allows direct installation via deferred component name as a string.
|
||||
|
||||
This installation path may be used for two purposes:
|
||||
|
||||
* Installing asset-only deferred components that do not have any Dart code to call `loadLibrary()` on.
|
||||
* Pre-downloading components to use later. However, `loadLibrary()` must still be called in order to use any dart code from the pre-downloaded component. This is useful when the exact dart library needed is not known yet.
|
||||
|
||||
The direct API uses platform channels to directly invoke the `installDeferredComponent` method on the `DynamicFeatureManager` and will not trigger any of the dart code packed in the component to load due to lack of a specified loading unit. Assets will be loaded. To use any dart code, `loadLibrary()` must still be called.
|
||||
|
||||
### Uninstallation
|
||||
|
||||
The [DeferredComponent](https://master-api.flutter.dev/flutter/services/DeferredComponent-class.html) framework utility class also provides an `uninstallDeferredComponent` method that uses platform channels to request that the OS uninstall and remove the files associated with the specified deferred component. Uninstallation is dependent on how the platform handles it and in Android's case, the removal of the files is queued and may take a long time before actually executed.
|
||||
|
||||
Uninstallation may only be requested directly with the string name of the component to be uninstalled. Uninstallation by loading unit id or direct call on a dart import is not yet supported.
|
||||
|
||||
## Tooling
|
||||
|
||||
Deferred components must be built as Android App Bundles (`.aab`) to function. If built as debug or an apk file, dart will compile normally and produce a single `.so` file.
|
||||
|
||||
Deferred components makes use of the existing `$ flutter build appbundle` command and checks for the existence of the `deferred-components:` entry in the `pubspec.yaml` to decide whether to build deferred or not. When the app is opted-in to deferred components and the build mode is release, `gen_snapshot` is passed a `--loading_unit_manifest` path, which tells `gen_snapshot` to attempt to produce split AOT artifacts. This includes a base file as well as a `.so` for every deferred library in the codebase. Each of these split units is called a "loading unit" and is assigned an internal integer ID called the loading unit ID.
|
||||
|
||||
The build process also relies on project setup to function. Each deferred component must correspond to an Android module defined in the `android` directory of your app. The base module is build as the `app` module while each additional component should have a module with the same name as the component. The base module `AndroidManifest.xml` also needs to include the mapping between loading unit IDs and deferred components.
|
||||
|
||||
The `flutter build appbundle` command assists in setting up the project with a validator that guides developers through the changes needed to build properly. This validator is necessary since the exact loading units produced by `gen_snapshot` is not known until `gen_snapshot` finishes compiling. Thus, some project setup can only be done after the `gen_snapshot` step in the build appbundle process.
|
||||
|
||||
Since mistakenly importing a deferred file as non-deferred can cause the file to be compiled into the base loading unit, the deferred components validator also has a mechanism for preventing accidental changes to the app's final generated loading units. This check will cause the build to fail if the generated loading units do not match the results of the previous run which is cached in the `deferred_components_loading_units.yaml` file. After throwing an error upon detecting changes, the build will automatically pass this check on next run if no additional changes are made. This means that this check is not error proof as you are still free to ignore the mismatched loading unit error if the change was intended and accounted for and continue to build.
|
||||
|
||||
***
|
||||
|
||||
# Fully deferring Flutter in add-to-app
|
||||
|
||||
When using add-to-app, it's possible to convert the entire Flutter module into an Android dynamic feature module to install at runtime.
|
||||
|
||||
Since the structures of add-to-app scenarios are highly variable, Flutter doesn't provide direct tooling to automate/validate full Flutter deferring. Instead, this guide provides details for implementing the components required for full Flutter deferring. The architecture described here is one of the many ways this can work, and is up to you to determine how best to integrate this into your apps.
|
||||
|
||||
Integrating full Flutter deferring is experimental. It requires custom implementations, and setup that is not fully tested due to variability in different apps. Therefore, this feature is considered a very advanced feature, and Flutter may not be able to provide guarantees or technical support for specific use cases.
|
||||
|
||||
Full Flutter deferral requires implementing `SplitInstallManager` in the base app module, as well as adding the dependency on `com.google.android.play:core` in `build.gradle` as an implementation. The dynamic feature module containing Flutter must depend on the base module.
|
||||
|
||||
The base module can no longer include any references to Flutter code. Therefore, the `:flutter` dependency in `build.gradle` should be removed.
|
||||
|
||||
The process described below uses the [fullscreen add-to-app example](https://github.com/flutter/samples/tree/master/add_to_app/fullscreen).
|
||||
|
||||
## SplitInstallManager base module "bootstrapper"
|
||||
|
||||
The base module must use `SplitInstallManager` to install the Flutter dynamic feature. For example, here is a bare-bones implementation called `SplitUtility` that downloads a dynamic feature module named `flutter` when `installFlutterModule` is called:
|
||||
|
||||
```java
|
||||
import android.annotation.SuppressLint;
|
||||
import android.content.Context;
|
||||
import androidx.annotation.NonNull;
|
||||
import com.google.android.play.core.splitinstall.SplitInstallException;
|
||||
import com.google.android.play.core.splitinstall.SplitInstallManager;
|
||||
import com.google.android.play.core.splitinstall.SplitInstallManagerFactory;
|
||||
import com.google.android.play.core.splitinstall.SplitInstallRequest;
|
||||
import com.google.android.play.core.splitinstall.SplitInstallSessionState;
|
||||
import com.google.android.play.core.splitinstall.SplitInstallStateUpdatedListener;
|
||||
import com.google.android.play.core.splitinstall.model.SplitInstallErrorCode;
|
||||
import com.google.android.play.core.splitinstall.model.SplitInstallSessionStatus;
|
||||
|
||||
class SplitUtility {
|
||||
private @NonNull SplitInstallManager splitInstallManager;
|
||||
private @NonNull FeatureInstallStateUpdatedListener listener;
|
||||
|
||||
private class FeatureInstallStateUpdatedListener implements SplitInstallStateUpdatedListener {
|
||||
@SuppressLint("DefaultLocale")
|
||||
public void onStateUpdate(SplitInstallSessionState state) {
|
||||
int sessionId = state.sessionId();
|
||||
switch (state.status()) {
|
||||
case SplitInstallSessionStatus.FAILED:
|
||||
break;
|
||||
case SplitInstallSessionStatus.INSTALLED:
|
||||
break;
|
||||
case SplitInstallSessionStatus.CANCELED:
|
||||
break;
|
||||
default:
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
SplitUtility(Context context) {
|
||||
splitInstallManager = SplitInstallManagerFactory.create(context);
|
||||
listener = new FeatureInstallStateUpdatedListener();
|
||||
splitInstallManager.registerListener(listener);
|
||||
}
|
||||
|
||||
void installFlutterModule() {
|
||||
SplitInstallRequest request =
|
||||
SplitInstallRequest.newBuilder().addModule("flutter").build();
|
||||
|
||||
splitInstallManager
|
||||
// Submits the request to install the module through the
|
||||
// asynchronous startInstall() task. Your app needs to be
|
||||
// in the foreground to submit the request.
|
||||
.startInstall(request)
|
||||
// Called when the install request is sent successfully. This is different than a successful
|
||||
// install which is handled in FeatureInstallStateUpdatedListener.
|
||||
.addOnSuccessListener(
|
||||
sessionId -> {
|
||||
// store sessionId somewhere if you want to reference it again.
|
||||
})
|
||||
.addOnFailureListener(
|
||||
exception -> {
|
||||
switch (((SplitInstallException) exception).getErrorCode()) {
|
||||
case SplitInstallErrorCode.NETWORK_ERROR:
|
||||
break;
|
||||
case SplitInstallErrorCode.MODULE_UNAVAILABLE:
|
||||
break;
|
||||
default:
|
||||
break;
|
||||
}
|
||||
});
|
||||
}
|
||||
|
||||
public void destroy() {
|
||||
splitInstallManager.unregisterListener(listener);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
The base module should install the Flutter module when appropriate. `PlayStoreDeferredComponentsManager` actually provides much of the same functionality, but it lives inside the Flutter Android embedding, and thus cannot be referenced from the base module.
|
||||
|
||||
## Project configuration
|
||||
|
||||
`build.gradle` of the base module as well as the flutter module should be modified to convert it into a dynamic feature module. The default Flutter android module used is located in the `.android/Flutter` directory.
|
||||
|
||||
It's recommended that you change the path of the Android module as the `.android` directory may be cleared or regenerated by cleaning tasks. You can set a different module or a clone of the default one as the module root directory with `project(":flutter").projectDir = new File(“<relative>.<path>.<to>.<module>”)` in your main android project’s `settings.gradle`.
|
||||
|
||||
The following configuration changes are the base changes needed to convert a fullscreen Flutter add-to-app implementation into a dynamic feature module.
|
||||
|
||||
Base module `build.gradle`:
|
||||
|
||||
* Add `dynamicFeatures = [':flutter']` to the `android` section of the base module `build.gradle`.
|
||||
* Remove `implementation project(':flutter')` from the dependencies section (the dynamic feature module must depend on the base module).
|
||||
* Add `implementation "com.google.android.play:core:1.8.0"` to the dependencies section.
|
||||
|
||||
Flutter module `build.gradle`:
|
||||
|
||||
* Replace `apply plugin: 'com.android.library'` with `apply plugin: 'com.android.dynamic-feature'` in the Flutter module `build.gradle`
|
||||
* Add a dependencies section to the Flutter module `build.gradle`:
|
||||
|
||||
```gradle
|
||||
dependencies {
|
||||
implementation fileTree(dir: "libs", include: ["*.jar"])
|
||||
implementation project(":app")
|
||||
api 'androidx.test:core:1.2.0'
|
||||
}
|
||||
```
|
||||
|
||||
Flutter module `AndroidManifest.xml`:
|
||||
|
||||
* Add `xmlns:dist="http://schemas.android.com/apk/distribution"` to the `manifest` section
|
||||
* Add the dynamic feature module section:
|
||||
|
||||
```xml
|
||||
<dist:module
|
||||
dist:instant="false"
|
||||
dist:title="@string/title_fluttermodule">
|
||||
<dist:delivery>
|
||||
<dist:on-demand />
|
||||
</dist:delivery>
|
||||
<dist:fusing dist:include="true" />
|
||||
</dist:module>
|
||||
```
|
||||
|
||||
Any references to the Flutter Java API will need to be done within your newly dynamic feature module. You are no longer able to directly launch a `FlutterActivity` from your main activity, and must now wrap it in a new class inside your dynamic feature module.
|
||||
|
||||
It is recommended to create a new Android Activity in your dynamic Flutter module that implements all of the behavior from your base application and base Activity. After installing the Flutter Android split, the new dynamic Flutter Activity can then be launched.
|
||||
|
||||
Depending on your specific apps, additional configuration may be needed to build and run your apps.
|
||||
|
||||
## Regular deferred components integration
|
||||
|
||||
We have not yet tested integration with a pure Flutter app using deferred components.
|
||||
|
||||
Flutter's tooling doesn't yet support building add-to-app and deferred components together. However, it is technically possible to run `gen_snapshot` in split AOT mode, and then package the different `.so` files into additional dynamic feature modules. See the Custom Implementation below for additional details.
|
||||
|
||||
***
|
||||
|
||||
# Custom Implementations
|
||||
|
||||
It's possible to write a custom implementation that bypasses the Android Play store. This is only recommended for advanced developers, and is primarily aimed at apps with very unique needs such as extremely large asset components, specific download behavior, or distribution in a region that does not have access to the Play Store (e.g. China).
|
||||
|
||||
### Overview
|
||||
|
||||
The Flutter Embedder allows custom implementations that handle customer-unique download and unpacking of deferred components while still allowing access to the core Dart callbacks that register a loading unit with the Dart runtime. This process is far more involved than the default play store version.
|
||||
|
||||
To implement a custom deferred components system, the following major pieces are required:
|
||||
|
||||
* Android embedder implementation of `DeferredComponentManager` that handles communication between the app and the server as well as extracting the `.so` file and assets from the downloaded component.
|
||||
* Tooling to package the components in a way that is compatible with your `DeferredComponentManager` and to interpret `gen_snapshot` output of loading units.
|
||||
* A server to host the downloadable components. Without the Play Store acting as a distributor for Android dynamic feature modules, this must be custom.
|
||||
|
||||
The following sections provide a high level guide of what needs to be done in a custom implementation.
|
||||
|
||||
### DeferredComponentManager - Android Embedder
|
||||
|
||||
The Embedder is responsible for downloading and installing the packaged component files. This can be done by implementing the abstract class `DeferredComponentManager` in the Android Embedder.
|
||||
|
||||
The entry point into this class is `installDeferredComponent` which provides both a loading unit id and the component name to help determine what to install.
|
||||
|
||||
`loadLibrary()` calls will pass only a loading unit id while `DeferredComponent.installDeferredComponent()` calls from the framework services package will pass only a component name to load an assets-only component.
|
||||
|
||||
In order to resolve a specific component from the loading unit id, it is typically necessary to store a mapping of loading unit ids to the component name. In the default implementation, we accomplish this by storing a string meta-data in the base app’s `AndroidManifest.xml`, but this can be accomplished in any way desired.
|
||||
|
||||
You may find detailed explanations of each method in `DeferredComponentManager` in the engine source file at `shell/platform/android/io/flutter/embedding/engine/deferredcomponents/DeferredComponentManager.java`.
|
||||
|
||||
The default Play Store implementation is found at `shell/platform/android/io/flutter/embedding/engine/deferredcomponents/PlayStoreDeferredComponentManager.java` and can be used as a rough guide on what needs to be implemented.
|
||||
|
||||
To load Dart libraries, call `FlutterJNI.loadDartDeferredLibrary` with the loading unit id, and a list of paths that potentially contain the `.so` file in your `loadDartLibrary` implementation. The engine will call `dlopen` on each of the paths provided until one is successfully opened.
|
||||
|
||||
To load new assets, create an Android `AssetManager` that has access to the newly downloaded assets. Pass this `AssetManager` to `FlutterJNI.updateJavaAssetManager`.
|
||||
|
||||
The `FlutterJNI` instance is passed in via `setJNI`.
|
||||
|
||||
### Tooling
|
||||
|
||||
Flutter’s tooling comes with the capability to instruct `gen_snapshot` to build split AOT, and pack the `.so` files and assets into an Android dynamic feature module.
|
||||
|
||||
Custom implementations are typically unable to make use of this tooling. Therefore, you may have to write custom tooling to package the `.so` files and assets, so they work alongside the custom `DeferredComponentManager` implementation.
|
||||
|
||||
To make `gen_snapshot` generate loading units, and the `.so` shared libraries, pass the `--loading_unit_manifest=<manifestPath>` option to `gen_snapshot`.
|
||||
|
||||
This will create a .json file at your `manifestPath` that contains the loading units and corresponding `.so` libs generated. The `.so` file and assets can then be packed in whatever format you wish to distribute on your file server. It is also your responsibility to unpack this format in your `DeferredComponentManager` implementation.
|
||||
|
||||
### File server
|
||||
|
||||
Since custom implementations typically do not use the Play store, a custom system for hosting and serving files to end users should be implemented. This part is highly variable in how it can be accomplished, and the only requirement is that it functions in tandem with the `DeferredComponentManager` implementation, so it delivers the files needed to load Dart shared libraries, and assets.
|
@ -1 +0,0 @@
|
||||
This document has been moved to https://flutter.dev/docs/development/add-to-app/android/add-flutter-screen
|
@ -1 +0,0 @@
|
||||
See [Add a Flutter Fragment to an Android App](https://www.google.com/url?q=https://docs.flutter.dev/add-to-app/android/add-flutter-fragment&sa=D&source=editors&ust=1715879907376746&usg=AOvVaw3G6E8LxUnKldq2WVx0CsZW)
|
@ -1 +0,0 @@
|
||||
See https://docs.flutter.dev/development/platform-integration/android/plugin-api-migration for the final version of this document.
|
@ -1 +0,0 @@
|
||||
See [Flutter Crash Reporting](https://www.google.com/url?q=https://docs.flutter.dev/reference/crash-reporting&sa=D&source=editors&ust=1715879907377300&usg=AOvVaw00lY-HSrn9NegCyjA5TTiG)
|
@ -1,37 +0,0 @@
|
||||
A loose catalog of resources for casual game development with Flutter.
|
||||
|
||||
## Game engines and tools
|
||||
|
||||
- [Flame Engine (2D game engine)](https://flame-engine.org/)
|
||||
- [Bonfire (RPG games)](https://pub.dev/packages/bonfire)
|
||||
- [SpriteWidget](https://github.com/spritewidget/spritewidget)
|
||||
- [Flutter Processing](https://github.com/matthew-carroll/flutter_processing)
|
||||
- [Rive (animation designer)](https://rive.app/)
|
||||
- [StageXl (Dart+Web, but not Flutter)](http://www.stagexl.org/)
|
||||
|
||||
## Games built with Flutter / developer experiences
|
||||
- [4 Pics 1 Word](https://play.google.com/store/apps/details?id=de.lotum.whatsinthefoto.us)
|
||||
- [Tomb Toad](http://www.missionctrlgames.com/) | [tweet](https://twitter.com/missionctrlgame/status/1329149448971280385)
|
||||
- [Flame Game Jam entries](https://itch.io/jam/1st-flame-game-jam/entries)
|
||||
- [A list of Flutter games built on top of Flame](https://flame-engine-store.web.app/#/)
|
||||
- [Porting an iOS game to Flutter](https://twitter.com/drcoderz/status/1458449373424062474)
|
||||
- [Space Empire](https://github.com/SatyamX64/space_empires)
|
||||
- [Sunnyplace](https://play.google.com/store/apps/details?id=br.com.sunnyplace)
|
||||
- [Tap Hero](https://github.com/mkiisoft/taphero)
|
||||
- [Pop, Pop, Win!](https://dart-lang.github.io/sample-pop_pop_win/) (Mine Sweeper w/ balloons and darts) – OG Dart+Web game w/ StageXL (not Flutter)
|
||||
- [Flutter Slide Puzzle](https://flutter.github.io/samples/web/slide_puzzle/) - Created for original Flutter web launch
|
||||
- [Community-submitted games](https://flutterawesome.com/tag/games/)
|
||||
- [Flutter Backgammon](https://github.com/csells/fibscli)
|
||||
|
||||
## Tutorials
|
||||
- [Building a snake game with Flutter](https://www.raywenderlich.com/19430602-how-to-create-a-2d-snake-game-in-flutter)
|
||||
- [Flappy Bird with Flutter Processing](https://www.youtube.com/watch?v=l2LO_pBEP5Y)
|
||||
- [Create a game with Flame Engine](https://blog.devowl.de/flutter-flame-step-1-create-your-game-b3b6ee387d77)
|
||||
- [Flutter games from scratch](https://www.youtube.com/playlist?list=PLlvRDpXh1Se6kipeBLiF1xByAEmxYie6J)
|
||||
|
||||
## Communities
|
||||
- [FlameCon](https://www.meetup.com/FlameCon/)
|
||||
|
||||
## Other useful resources
|
||||
- [Monetization](https://flutter.dev/ads)
|
||||
- [Firebase (auth, storage, hosting, testing, analytics, cloud functions)](https://firebase.flutter.dev/docs/overview)
|
@ -1,39 +0,0 @@
|
||||
This wiki is primarily aimed at engineers building or making contributions to Flutter.
|
||||
|
||||
If you are new to Flutter, then you will find more general information on the Flutter project, including tutorials and samples, on our Web site at [flutter.dev](https://flutter.dev). For specific information about Flutter's APIs, consider our API reference which can be found at the [api.flutter.dev](https://api.flutter.dev/).
|
||||
|
||||
If you want to know what we're likely to do in the future, our [[roadmap]] may be of interest.
|
||||
|
||||
If you intend to contribute to Flutter, welcome! You are encouraged to start with [our contributor guide](https://github.com/flutter/flutter/blob/master/CONTRIBUTING.md), which helps onboard new team members. It points to the most relevant pages on this wiki. You are also invited to join our [Discord](https://github.com/flutter/flutter/wiki/Chat) server.
|
||||
|
||||
## Search
|
||||
|
||||
[Search this wiki on Google](https://www.google.com/search?q=site%3Ahttps%3A%2F%2Fgithub.com%2Fflutter%2Fflutter%2Fwiki%2F).
|
||||
|
||||
## Index of notable sections
|
||||
|
||||
* [Actionable bugs](https://github.com/flutter/flutter/wiki/Triage#what-makes-an-issue-actionable), and the closing of unactionable bugs
|
||||
* [Breaking changes](https://github.com/flutter/flutter/wiki/Tree-hygiene#handling-breaking-changes)
|
||||
* [Cherrypick process](https://github.com/flutter/flutter/wiki/Flutter-Cherrypick-Process)
|
||||
* [Closing issues](https://github.com/flutter/flutter/wiki/Issue-hygiene#closing-issues)
|
||||
* [[Dashboards]]
|
||||
* [Debugging a broken engine autoroll](https://github.com/flutter/flutter/wiki/Debugging-the-engine#bisecting-a-roll-failure)
|
||||
* [Deprecations](https://github.com/flutter/flutter/wiki/Tree-hygiene#deprecations)
|
||||
* [[Design documents]]
|
||||
* [Discord](https://github.com/flutter/flutter/wiki/Chat)
|
||||
* [Engineering Philosophy](https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#philosophy)
|
||||
* [Flaky tests](https://github.com/flutter/flutter/wiki/Issue-hygiene#flaky-tests)
|
||||
* [[flutter.dev is down|In case of emergency]]
|
||||
* [Issue prioritization](https://github.com/flutter/flutter/wiki/Issue-hygiene#priorities)
|
||||
* [Labels](https://github.com/flutter/flutter/wiki/Issue-hygiene#labels)
|
||||
* [Milestones](https://github.com/flutter/flutter/wiki/Issue-hygiene#milestones)
|
||||
* [Plugin compatibility policy](https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#plugin-compatibility)
|
||||
* [Reviewing code](https://github.com/flutter/flutter/wiki/Tree-hygiene#how-to-review-code)
|
||||
* [RFC process](https://github.com/flutter/flutter/wiki/Issue-hygiene#how-to-propose-a-specific-change)
|
||||
* [Status of popular issues](https://github.com/flutter/flutter/wiki/Popular-issues)
|
||||
* [Submitting code, process for](https://github.com/flutter/flutter/wiki/Tree-hygiene#overview)
|
||||
* [Support levels, definitions of](https://github.com/flutter/flutter/wiki/Values#support)
|
||||
* [Symbolicating stack traces](https://github.com/flutter/flutter/wiki/Crashes)
|
||||
* [Threading in the Engine](https://github.com/flutter/flutter/wiki/The-Engine-architecture#threading)
|
||||
* [When will my bug be fixed?](https://github.com/flutter/flutter/wiki/Issue-hygiene#when-will-my-bug-be-fixed)
|
||||
* [Security best practices](https://github.com/flutter/flutter/wiki/security#Best-practices)
|
@ -1,8 +0,0 @@
|
||||
This page contains weekly issue triage reports from the Nevercode front-line triage team.
|
||||
|
||||
- [2024 reports](https://github.com/flutter/flutter/wiki/2024-Issue-Triage-Reports)
|
||||
- [2023 reports](https://github.com/flutter/flutter/wiki/2023-Issue-Triage-Reports)
|
||||
- [2022 reports](https://github.com/flutter/flutter/wiki/2022---Issue-Triage-Reports)
|
||||
- [2021 reports](https://github.com/flutter/flutter/wiki/2021---Issue-Triage-Reports)
|
||||
|
||||
_See also: [[Triage]]_
|
@ -1,40 +0,0 @@
|
||||
Code obfuscation hides function and class names in your compiled Dart code, making it difficult for an attacker to reverse engineer your proprietary app. This can be enabled with the `--obfuscate` option, which is required to be paired with `--split-debug-info` to generate a symbol map.
|
||||
|
||||
|
||||
<i>As of flutter 1.16.2, the information below is out of date. Only use this if you're on an earlier version of Flutter. If you are using Flutter 1.16.2 or later, please refer to [Obfuscating Dart code](https://flutter.dev/docs/deployment/obfuscate) on flutter.dev.</i>
|
||||
|
||||
## Android
|
||||
|
||||
Add the following line to `<ProjectRoot>/android/gradle.properties`:
|
||||
|
||||
```
|
||||
extra-gen-snapshot-options=--obfuscate
|
||||
```
|
||||
For information on obfuscating the Android host, see [Enabling Proguard](https://flutter.dev/android-release/#enabling-proguard) in [Preparing an Android App for Release](https://flutter.dev/android-release/#minify-and-obfuscate).
|
||||
|
||||
## iOS
|
||||
|
||||
### Step 1 - Modify the "build aot" call
|
||||
|
||||
Add the following flag to the `build aot` call in the `<FlutterRoot>/packages/flutter_tools/bin/xcode_backend.sh` file:
|
||||
|
||||
```
|
||||
${extra_gen_snapshot_options_or_none}
|
||||
```
|
||||
|
||||
Define this flag as follows:
|
||||
|
||||
```
|
||||
local extra_gen_snapshot_options_or_none=""
|
||||
if [[ -n "$EXTRA_GEN_SNAPSHOT_OPTIONS" ]]; then
|
||||
extra_gen_snapshot_options_or_none="--extra-gen-snapshot-options=$EXTRA_GEN_SNAPSHOT_OPTIONS"
|
||||
fi
|
||||
```
|
||||
|
||||
### Step 2 - Modify the release config
|
||||
|
||||
In `<ProjectRoot>/ios/Flutter/Release.xcconfig`, add the following line:
|
||||
|
||||
```
|
||||
EXTRA_GEN_SNAPSHOT_OPTIONS=--obfuscate
|
||||
```
|
@ -1 +0,0 @@
|
||||
This page has moved to [Reduce shader compilation jank](https://flutter.dev/docs/perf/rendering/shader) on flutter.dev.
|
@ -1,88 +0,0 @@
|
||||
<!-- Don't add user documentation to the wiki. User documentation belongs on the web site. -->
|
||||
<!-- We only have these pages for historical reasons. -->
|
||||
|
||||
Flutter's user-facing documentation should all be on the Flutter web site and the API documentation site:
|
||||
|
||||
- https://docs.flutter.dev/
|
||||
- [Release notes](https://flutter.dev/docs/development/tools/sdk/release-notes)
|
||||
- https://api.flutter.dev/
|
||||
|
||||
Historically, experimental documentation was sometimes first written on this wiki and later moved to the web site. This is
|
||||
now discouraged but some of the content created in this way still exists and is listed below.
|
||||
|
||||
_Contributors: please consider moving this content to the web site or deleting it if it is no longer applicable!_
|
||||
|
||||
## Old documentation
|
||||
|
||||
## General
|
||||
|
||||
<!-- don't add things here; if you have a new feature, it should be documented on the web site not the wiki -->
|
||||
- [Apple Silicon support](https://github.com/flutter/flutter/wiki/Developing-with-Flutter-on-Apple-Silicon)
|
||||
- [[Bad Builds]]
|
||||
- [[Binding to native code via FFI]] (moved to website)
|
||||
- [[Code generation in Flutter]]
|
||||
- [[Codelabs]]
|
||||
- [[Data-driven Fixes]]
|
||||
- [[Desktop shells]]
|
||||
- [[Deferred Components]]
|
||||
- [[Flutter CLI crash reporting]]
|
||||
- [Flutter CLI custom embedder support](https://github.com/flutter/flutter/wiki/Using-custom-embedders-with-the-Flutter-CLI)
|
||||
- [[Flutter Test Fonts]]
|
||||
- [[Game development with Flutter]]
|
||||
- [[Hybrid Composition]]
|
||||
- [[IntelliJ - Flutter Setup Tips and Tricks]]
|
||||
- [JIT release builds](https://github.com/flutter/flutter/wiki/JIT-Release-Modes)
|
||||
- [[Making animated GIFs of Flutter apps]]
|
||||
- [[Multi-device debugging in VS Code]]
|
||||
- [Null safety package migration status](https://github.com/dart-lang/sdk/wiki/Null-safety-migration-status)
|
||||
- [[Obfuscating Dart Code]]
|
||||
- [[Reduce shader compilation jank using SkSL warm up]] (moved to website)
|
||||
- [[Upgrading Flutter projects from using PlatformMessages to using channels]]
|
||||
- [[Writing Effective Tests]]
|
||||
|
||||
### Android
|
||||
<!-- don't add things here; user documentation belongs on the web site not the wiki -->
|
||||
- [Android Fast Start](https://github.com/flutter/flutter/wiki/Fast-Start)
|
||||
- [[Android Platform Views]]
|
||||
- [[Experimental: Add Flutter Activity]] (moved to website)
|
||||
- [[Experimental: Add Flutter Fragment]]
|
||||
- [[Experimental: Add Flutter Fragment ViewPager]]
|
||||
- [[Experimental: Add Flutter View]]
|
||||
- [[Experimental: Create Flutter Plugin]] (moved to website)
|
||||
- [[Experimental: Launch Flutter with non main entrypoint]]
|
||||
- [[Experimental: Reuse FlutterEngine across screens]]
|
||||
- [[Experimental: Use old plugins with new embedding]]
|
||||
- [[How Flutter apps are compiled with Gradle for Android]]
|
||||
- [[Hybrid Composition|Hybrid Composition#Android]]
|
||||
- [Multidex](https://github.com/flutter/flutter/wiki/Android-Multidex-support)
|
||||
- [[Texture Layer Hybrid Composition]]
|
||||
- [[Upgrading Flutter projects to build with gradle]]
|
||||
- [[Upgrading Flutter projects to Gradle 4.1 and Android Studio Gradle plugin 3.0.1]]
|
||||
- [[Upgrading pre 1.12 Android projects]]
|
||||
|
||||
### iOS
|
||||
<!-- don't add things here; user documentation belongs on the web site not the wiki -->
|
||||
- [[Creating an iOS Bitcode enabled app]]
|
||||
- [[Hybrid Composition|Hybrid Composition#iOS]]
|
||||
- [[Hybrid Composition iOS]]
|
||||
- [[PID leak in iOS development workflow]]
|
||||
- [[State of Catalina Support]] in Flutter 1.9.
|
||||
- [[Upgrading Flutter added to existing iOS Xcode project]]
|
||||
|
||||
### Web
|
||||
<!-- don't add things here; user documentation belongs on the web site not the wiki -->
|
||||
- [[Debugging issues on the Web]]
|
||||
- [[Running Flutter Driver tests with Web]]
|
||||
- [[Upgrading from package:flutter_web to the Flutter SDK]]
|
||||
|
||||
### Release notes
|
||||
<!-- don't add things here; user documentation belongs on the web site not the wiki -->
|
||||
- [[Hotfixes to the Stable Channel]]
|
||||
- [[Release Notes - Changes in 1.2.1]]
|
||||
- [[Release Notes - Flutter 1.2.1]]
|
||||
- [[Commits Between 1.2.1 and 1.5.4]]
|
||||
- [[Release Notes Flutter 1.5.4]]
|
||||
- [[PRs addressed between 1.5.4 and 1.7.8]]
|
||||
- [[Release Notes Flutter 1.7.8]]
|
||||
- [[PRs merged between 1.7.8 and 1.9.1]]
|
||||
- [[Release Notes Flutter 1.9.1]]
|
@ -40,4 +40,4 @@ Next, alter your `FragmentPagerAdapter` to return a `FlutterFragment` for the de
|
||||
|
||||
You should now have a Flutter UI as one or more pages within your tabbed navigation.
|
||||
|
||||
You may notice a delay between creation of your `FlutterFragment` and the display of your Flutter UI. This delay is caused by the warm-up time for the `FlutterEngine`. This warm-up issue a standard concern that applies to all uses of Flutter, including `FlutterActivity`. The way to minimize this visual delay is to use pre-warmed `FlutterEngine`s. Please see [the page about pre-warming FlutterEngines](https://github.com/flutter/flutter/wiki/Experimental:-Reuse-FlutterEngine-across-screens).
|
||||
You may notice a delay between creation of your `FlutterFragment` and the display of your Flutter UI. This delay is caused by the warm-up time for the `FlutterEngine`. This warm-up issue a standard concern that applies to all uses of Flutter, including `FlutterActivity`. The way to minimize this visual delay is to use pre-warmed `FlutterEngine`s. Please see [the page about pre-warming FlutterEngines](Experimental-Reuse-FlutterEngine-across-screens.md).
|
@ -4,10 +4,9 @@ _**Everything in this doc and linked from this doc is experimental. These detail
|
||||
|
||||
Flutter can be added to an Android app as a single `View` in an `Activity`'s `View` hierarchy.
|
||||
|
||||
Before adding Flutter as a single `View`, you should consider if it is possible to add Flutter as a `Fragment` or an `Activity` to reduce your development burden.
|
||||
Before adding Flutter as a single `View`, you should consider if it is possible to add Flutter as a `Fragment` to reduce your development burden.
|
||||
|
||||
* [How to use a `FlutterActivity`](https://github.com/flutter/flutter/wiki/Experimental:-Add-Flutter-Activity)
|
||||
* [How to use a `FlutterFragment`](https://github.com/flutter/flutter/wiki/Experimental:-Add-Flutter-Fragment)
|
||||
* [How to use a `FlutterFragment`](Experimental-Add-Flutter-Fragment-ViewPager.md)
|
||||
|
||||
If you really need to add Flutter as a single `View` then do the following.
|
||||
|
||||
@ -15,7 +14,7 @@ If you really need to add Flutter as a single `View` then do the following.
|
||||
|
||||
### Create and start a FlutterEngine
|
||||
|
||||
Create and start a `FlutterEngine` by following the appropriate instructions. See the [FlutterEngine page](https://github.com/flutter/flutter/wiki/Experimental:-Reuse-FlutterEngine-across-screens)
|
||||
Create and start a `FlutterEngine` by following the appropriate instructions. See the [FlutterEngine page](Experimental-Reuse-FlutterEngine-across-screens.md)
|
||||
|
||||
### Create a FlutterView and add to layout
|
||||
|
@ -32,14 +32,6 @@ engine.getDartExecutor().executeDartEntrypoint(entrypoint);
|
||||
|
||||
To cache one or more `FlutterEngine`s, store the initialized `FlutterEngine`s in a central place that you can access from your desired `Activity`s and `Fragment`s. You could choose to store these `FlutterEngine`s in your `Application` subclass, or you could store them in a statically accessible location of your choice. This choice is up to you, and should consider your specific application architecture and development practices.
|
||||
|
||||
## Using a cached FlutterEngine in a FlutterActivity
|
||||
|
||||
See the [FlutterActivity page](https://github.com/flutter/flutter/wiki/Experimental:-Add-Flutter-Activity#using-a-cached-flutterengine)
|
||||
|
||||
## Using a cached FlutterEngine in a FlutterFragment
|
||||
|
||||
See the [FlutterFragment page](https://github.com/flutter/flutter/wiki/Experimental:-Add-Flutter-Activity#using-a-cached-flutterengine)
|
||||
|
||||
## Dart entrypoint restrictions
|
||||
|
||||
A `FlutterEngine` can only execute a Dart entrypoint one time. Once a `FlutterEngine` has started executing Dart code, it will continue to execute that Dart code until the `FlutterEngine` is disposed. To re-use a `FlutterEngine` that needs to display different experiences at different times you will need to find an approach that accomplishes your goals without restarting Dart execution. Below are a couple options.
|
@ -0,0 +1,8 @@
|
||||
This page contains weekly issue triage reports from the Nevercode front-line triage team.
|
||||
|
||||
- [2024 reports](2024-Issue-Triage-Reports.md)
|
||||
- [2023 reports](2023-Issue-Triage-Reports.md)
|
||||
- [2022 reports](2022---Issue-Triage-Reports.md)
|
||||
- [2021 reports](2021---Issue-Triage-Reports.md)
|
||||
|
||||
_See also: [Triage](../../triage/README.md)_
|
@ -114,7 +114,7 @@ with code like this
|
||||
throw new PlatformException(errorCode, anErrorMessage, someDetails);
|
||||
});
|
||||
|
||||
See [platform_channel](https://github.com/flutter/flutter/blob/master/examples/platform_channel/lib/main.dart) for an example.
|
||||
See [platform_channel](../../examples/platform_channel/lib/main.dart) for an example.
|
||||
|
||||
## Android side
|
||||
|
||||
@ -134,7 +134,7 @@ Similar to Flutter side, using `FlutterMessageChannel` and `FlutterMethodChannel
|
||||
}
|
||||
});
|
||||
|
||||
[API documentation](https://docs.flutter.io/javadoc/). See [platform_channel](https://github.com/flutter/flutter/blob/master/examples/platform_channel/android/app/src/main/java/com/example/platformchannel/MainActivity.java) for another example.
|
||||
[API documentation](https://docs.flutter.io/javadoc/). See [platform_channel](../../examples/platform_channel/android/app/src/main/java/com/example/platformchannel/MainActivity.java) for another example.
|
||||
|
||||
## iOS side
|
||||
|
||||
@ -155,4 +155,4 @@ Similar to Flutter side, using `FlutterMessageChannel` and `FlutterMethodChannel
|
||||
}];
|
||||
|
||||
|
||||
[API documentation](https://github.com/flutter/engine/blob/master/shell/platform/darwin/ios/framework/Headers). See [platform_channel](https://github.com/flutter/flutter/blob/master/examples/platform_channel/ios/Runner/AppDelegate.m) for another example.
|
||||
[API documentation](https://github.com/flutter/engine/blob/main/shell/platform/darwin/ios/framework/Headers). See [platform_channel](../../examples/platform_channel/ios/Runner/AppDelegate.m) for another example.
|
57
docs/wiki_archive/User-documentation-index.md
Normal file
57
docs/wiki_archive/User-documentation-index.md
Normal file
@ -0,0 +1,57 @@
|
||||
<!-- Don't add user documentation to the wiki. User documentation belongs on the web site. -->
|
||||
<!-- We only have these pages for historical reasons. -->
|
||||
|
||||
Flutter's user-facing documentation should all be on the Flutter web site and the API documentation site:
|
||||
|
||||
- https://docs.flutter.dev/
|
||||
- [Release notes](https://flutter.dev/docs/development/tools/sdk/release-notes)
|
||||
- https://api.flutter.dev/
|
||||
|
||||
Historically, experimental documentation was sometimes first written on this wiki and later moved to the web site. This is
|
||||
now discouraged but some of the content created in this way still exists and is listed below.
|
||||
|
||||
_Contributors: please consider moving this content to the web site or deleting it if it is no longer applicable!_
|
||||
|
||||
## Old documentation
|
||||
|
||||
## General
|
||||
|
||||
<!-- don't add things here; if you have a new feature, it should be documented on the web site not the wiki -->
|
||||
- [Apple Silicon support](../platforms/desktop/macos/Developing-with-Flutter-on-Apple-Silicon.md)
|
||||
- [Bad Builds](../releases/Bad-Builds.md)
|
||||
- [Binding to native code via FFI](https://flutter.dev/docs/development/platform-integration/c-interop)
|
||||
- [Data-driven Fixes](../contributing/Data-driven-Fixes.md)
|
||||
- [Flutter CLI crash reporting](https://docs.flutter.dev/reference/crash-reporting)
|
||||
- [Flutter CLI custom embedder support](../tool/Using-custom-embedders-with-the-Flutter-CLI.md)
|
||||
- [Flutter Test Fonts](../contributing/testing/Flutter-Test-Fonts.md)
|
||||
- [Hybrid Composition](../platforms/Hybrid-Composition.md)
|
||||
- [IntelliJ - Flutter Setup Tips and Tricks](IntelliJ---Flutter-Setup-Tips-and-Tricks.md)
|
||||
- [JIT release builds](../engine/JIT-Release-Modes.md)
|
||||
- [Making animated GIFs of Flutter apps](../contributing/issue_hygiene/Making-animated-GIFs-of-Flutter-apps.md)
|
||||
- [Multi-device debugging in VS Code](Multi-device-debugging-in-VS-Code.md)
|
||||
- [Obfuscating Dart Code](https://flutter.dev/docs/deployment/obfuscate)
|
||||
- [Reduce shader compilation jank using SkSL warm up](https://flutter.dev/docs/perf/rendering/shader)
|
||||
- [Upgrading Flutter projects from using PlatformMessages to using channels](Upgrading-Flutter-projects-from-using-PlatformMessages-to-using-channels.md)
|
||||
- [Writing Effective Tests](../contributing/testing/Writing-Effective-Tests.md)
|
||||
|
||||
### Android
|
||||
<!-- don't add things here; user documentation belongs on the web site not the wiki -->
|
||||
- [Android Fast Start](../tool/Fast-Start.md)
|
||||
- [Android Platform Views](../platforms/android/Android-Platform-Views.md)
|
||||
- [How Flutter apps are compiled with Gradle for Android](../platforms/android/How-Flutter-apps-are-compiled-with-Gradle-for-Android.md)
|
||||
- [Hybrid Composition](../platforms/Hybrid-Composition.md#android)
|
||||
- [Multidex](../platforms/android/Android-Multidex-support.md)
|
||||
- [Texture Layer Hybrid Composition](../platforms/android/Texture-Layer-Hybrid-Composition.md)
|
||||
|
||||
### iOS
|
||||
<!-- don't add things here; user documentation belongs on the web site not the wiki -->
|
||||
- [Hybrid Composition iOS](../platforms/Hybrid-Composition.md#ios)
|
||||
|
||||
### Web
|
||||
<!-- don't add things here; user documentation belongs on the web site not the wiki -->
|
||||
- [Debugging issues on the Web](../platforms/web/Debugging-issues-on-the-Web.md)
|
||||
- [Running Flutter Driver tests with Web](../contributing/testing/Running-Flutter-Driver-tests-with-Web.md)
|
||||
|
||||
### Release notes
|
||||
<!-- don't add things here; user documentation belongs on the web site not the wiki -->
|
||||
- [Hotfixes to the Stable Channel](../releases/Hotfixes-to-the-Stable-Channel.md)
|
@ -1,23 +1,5 @@
|
||||
////
|
||||
Enable icons for admonitions
|
||||
From https://gist.github.com/dcode/0cfbf2699a1fe9b46ff04c41721dda74#admonitions
|
||||
////
|
||||
ifdef::env-github[]
|
||||
:tip-caption: :bulb:
|
||||
:note-caption: :information_source:
|
||||
:important-caption: :heavy_exclamation_mark:
|
||||
:caution-caption: :fire:
|
||||
:warning-caption: :warning:
|
||||
endif::[]
|
||||
|
||||
|
||||
:toc:
|
||||
:toc-placement!:
|
||||
|
||||
Common issues Flutter developers might run into and recipes how to fix or work around.
|
||||
|
||||
toc::[]
|
||||
|
||||
= Flutter Recipes
|
||||
|
||||
== Flutter installation
|
||||
@ -134,10 +116,6 @@ In a network where the Internet can only be reached through a proxy and Flutter
|
||||
|
||||
Proxy setting incomplete or invalid.
|
||||
|
||||
==== Ways to fix
|
||||
|
||||
- See https://github.com/flutter/flutter/wiki/Using-Flutter-in-China
|
||||
|
||||
==== Related information
|
||||
(none yet)
|
||||
|
Loading…
Reference in New Issue
Block a user