文件最后提交记录最后更新时间
[all] Omit obvious local types (#10511) Makes the analysis options changes described in https://github.com/flutter/flutter/issues/178827: - Adding [omit_obvious_local_variable_types](https://dart.dev/tools/linter-rules/omit_obvious_local_variable_types) - Adding [specify_nonobvious_local_variable_types](https://dart.dev/tools/linter-rules/specify_nonobvious_local_variable_types) - Adding [specify_nonobvious_property_types](https://dart.dev/tools/linter-rules/specify_nonobvious_property_types) - Adding [type_annotate_public_apis](https://dart.dev/tools/linter-rules/type_annotate_public_apis) - Removing [always_specify_types](https://dart.dev/tools/linter-rules/always_specify_types) After those changes, makes the following repo-wide changes: - dart fix --apply in all packages and in script/tool/ - dart format in all packages and in script/tool/ - update-excerpts repo tooling command to update excerpts based on the changes to their sources Also updates the min Flutter/Dart SDK version to 3.35/3.9 for the following packages, to avoid analyze failures in the N-2 legacy analysis run due to what appears to be a 3.9 change in what the Dart analyzer continues to be an obvious local type in loop iterations: - go_router - google_fonts - google_identity_services_web - google_maps_flutter_web - local_auth_platform_interface - metrics_center - multicast_dns - pigeon - rfw - shared_preferences - two_dimensional_scrollables - vector_graphics_compiler - mustache_template - path_parsing Because this is causing a significant amount of format churn already, I took this opportunity to update the repository tooling to a min Dart SDK of 3.8 (the N-2 stable version, so the earliest version we need the tooling to support) to pick up the new format style, so the amount of automated formatter change is higher in script/tool/ than in the packages. This does contain two manual changes (other than the repo tooling min version): - https://github.com/flutter/packages/commit/d700b45c7df3a79f66dc119ad36dd2bc1e042acf changes dynamic to Object? in a few places where dynamic caused analyzer warnings under the new rule set. - Updates the repo tooling to ignore .dart_tool/ when looking for unexpected local analysis_options.yaml files, to fix issues running the repo tool's analyze command locally based on recent changes in dart behavior. This does not include any CHANGELOG or version updates; even though we normally version any changes to production code, mass automated changes like this aren't worth the churn of releasing. This includes changes to lib/example/main.dart and to README.md excerpts; while the style changes will be user-visible on pub.dev, it's fine for those changes to wait for the next release of each package. Part of https://github.com/flutter/flutter/issues/1788276 个月前
[all] Omit obvious local types (#10511) Makes the analysis options changes described in https://github.com/flutter/flutter/issues/178827: - Adding [omit_obvious_local_variable_types](https://dart.dev/tools/linter-rules/omit_obvious_local_variable_types) - Adding [specify_nonobvious_local_variable_types](https://dart.dev/tools/linter-rules/specify_nonobvious_local_variable_types) - Adding [specify_nonobvious_property_types](https://dart.dev/tools/linter-rules/specify_nonobvious_property_types) - Adding [type_annotate_public_apis](https://dart.dev/tools/linter-rules/type_annotate_public_apis) - Removing [always_specify_types](https://dart.dev/tools/linter-rules/always_specify_types) After those changes, makes the following repo-wide changes: - dart fix --apply in all packages and in script/tool/ - dart format in all packages and in script/tool/ - update-excerpts repo tooling command to update excerpts based on the changes to their sources Also updates the min Flutter/Dart SDK version to 3.35/3.9 for the following packages, to avoid analyze failures in the N-2 legacy analysis run due to what appears to be a 3.9 change in what the Dart analyzer continues to be an obvious local type in loop iterations: - go_router - google_fonts - google_identity_services_web - google_maps_flutter_web - local_auth_platform_interface - metrics_center - multicast_dns - pigeon - rfw - shared_preferences - two_dimensional_scrollables - vector_graphics_compiler - mustache_template - path_parsing Because this is causing a significant amount of format churn already, I took this opportunity to update the repository tooling to a min Dart SDK of 3.8 (the N-2 stable version, so the earliest version we need the tooling to support) to pick up the new format style, so the amount of automated formatter change is higher in script/tool/ than in the packages. This does contain two manual changes (other than the repo tooling min version): - https://github.com/flutter/packages/commit/d700b45c7df3a79f66dc119ad36dd2bc1e042acf changes dynamic to Object? in a few places where dynamic caused analyzer warnings under the new rule set. - Updates the repo tooling to ignore .dart_tool/ when looking for unexpected local analysis_options.yaml files, to fix issues running the repo tool's analyze command locally based on recent changes in dart behavior. This does not include any CHANGELOG or version updates; even though we normally version any changes to production code, mass automated changes like this aren't worth the churn of releasing. This includes changes to lib/example/main.dart and to README.md excerpts; while the style changes will be user-visible on pub.dev, it's fine for those changes to wait for the next release of each package. Part of https://github.com/flutter/flutter/issues/1788276 个月前
[all] Omit obvious local types (#10511) Makes the analysis options changes described in https://github.com/flutter/flutter/issues/178827: - Adding [omit_obvious_local_variable_types](https://dart.dev/tools/linter-rules/omit_obvious_local_variable_types) - Adding [specify_nonobvious_local_variable_types](https://dart.dev/tools/linter-rules/specify_nonobvious_local_variable_types) - Adding [specify_nonobvious_property_types](https://dart.dev/tools/linter-rules/specify_nonobvious_property_types) - Adding [type_annotate_public_apis](https://dart.dev/tools/linter-rules/type_annotate_public_apis) - Removing [always_specify_types](https://dart.dev/tools/linter-rules/always_specify_types) After those changes, makes the following repo-wide changes: - dart fix --apply in all packages and in script/tool/ - dart format in all packages and in script/tool/ - update-excerpts repo tooling command to update excerpts based on the changes to their sources Also updates the min Flutter/Dart SDK version to 3.35/3.9 for the following packages, to avoid analyze failures in the N-2 legacy analysis run due to what appears to be a 3.9 change in what the Dart analyzer continues to be an obvious local type in loop iterations: - go_router - google_fonts - google_identity_services_web - google_maps_flutter_web - local_auth_platform_interface - metrics_center - multicast_dns - pigeon - rfw - shared_preferences - two_dimensional_scrollables - vector_graphics_compiler - mustache_template - path_parsing Because this is causing a significant amount of format churn already, I took this opportunity to update the repository tooling to a min Dart SDK of 3.8 (the N-2 stable version, so the earliest version we need the tooling to support) to pick up the new format style, so the amount of automated formatter change is higher in script/tool/ than in the packages. This does contain two manual changes (other than the repo tooling min version): - https://github.com/flutter/packages/commit/d700b45c7df3a79f66dc119ad36dd2bc1e042acf changes dynamic to Object? in a few places where dynamic caused analyzer warnings under the new rule set. - Updates the repo tooling to ignore .dart_tool/ when looking for unexpected local analysis_options.yaml files, to fix issues running the repo tool's analyze command locally based on recent changes in dart behavior. This does not include any CHANGELOG or version updates; even though we normally version any changes to production code, mass automated changes like this aren't worth the churn of releasing. This includes changes to lib/example/main.dart and to README.md excerpts; while the style changes will be user-visible on pub.dev, it's fine for those changes to wait for the next release of each package. Part of https://github.com/flutter/flutter/issues/1788276 个月前
Standardize Copyrights: Chromium->Flutter (#2996) In all copyright messages (and in the Xcode project organization name) standardize on "The Flutter Authors", adding "The Chromium Authors" to the Flutter AUTHORS list. This reduces inconsistency in the copyright lines in this repository, moving closer to a single consistent copyright+license (as in flutter/engine and flutter/flutter) Updates the validation script to no longer accept "The Chromium Authors" or "the Chromium project authors" in first-party code.5 年前
[various] Update READMEs to reflect current OS support (#10470) * Updates all READMEs to list the OS versions currently supported by the latest platform implementations. * This is not necessarily the same as the OS version that the current version of the app-facing platform supports; for plugins where the app-facing package still supports Flutter 3.32, clients using Flutter 3.32 will get older versions of the platform implementations that are still compatible with iOS 12/Android API 21-23. However, the Flutter team no longer actively supports those versions, which is what we are choosing to reflect in READMEs. (In the future, we may want to move this information to platform implementation package READMEs, although that will make it harder to skim.) * Updates all Android plugins that still listed a minSdkVersion of 21 to 24. * This is a no-op for clients; all of these implementation packages already require Flutter 3.35, which can only build for 24+. * This part is the Android version of https://github.com/flutter/packages/pull/10231, but no SDK changes were needed here. All the changes where we could make code changes were already done in https://github.com/flutter/packages/pull/9851. Fixes https://github.com/flutter/flutter/issues/178757 ## Pre-Review Checklist [^1]: Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling.5 个月前
Remove "All right reserved" from all files (#10066) Per guidance from legal on current preferred practice, remove "All rights reserved" from all LICENSE files and header blocks, and update the repo tool check accordingly.7 个月前
[various] Update READMEs to reflect current OS support (#10470) * Updates all READMEs to list the OS versions currently supported by the latest platform implementations. * This is not necessarily the same as the OS version that the current version of the app-facing platform supports; for plugins where the app-facing package still supports Flutter 3.32, clients using Flutter 3.32 will get older versions of the platform implementations that are still compatible with iOS 12/Android API 21-23. However, the Flutter team no longer actively supports those versions, which is what we are choosing to reflect in READMEs. (In the future, we may want to move this information to platform implementation package READMEs, although that will make it harder to skim.) * Updates all Android plugins that still listed a minSdkVersion of 21 to 24. * This is a no-op for clients; all of these implementation packages already require Flutter 3.35, which can only build for 24+. * This part is the Android version of https://github.com/flutter/packages/pull/10231, but no SDK changes were needed here. All the changes where we could make code changes were already done in https://github.com/flutter/packages/pull/9851. Fixes https://github.com/flutter/flutter/issues/178757 ## Pre-Review Checklist [^1]: Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling.5 个月前
Update repo for 3.38 (#10405) Does all of the steps from https://github.com/flutter/flutter/blob/master/docs/ecosystem/release/Updating-Packages-repo-for-a-stable-release.md for the 3.38 release (except the first one, which the stable roller will handle). This includes a lot of autoformat changes, because the N-2 is now 3.32, which means many packages are now being updated to a min Dart SDK of 3.8, triggering a formatter behavior change.6 个月前
README.md

url_launcher

pub package

A Flutter plugin for launching a URL.

Android iOS Linux macOS Web Windows
Support SDK 24+ 13.0+ Any 10.15+ Any Windows 10+

Example

import 'package:flutter/material.dart';
import 'package:url_launcher/url_launcher.dart';

final Uri _url = Uri.parse('https://flutter.dev');

void main() => runApp(
  const MaterialApp(
    home: Material(
      child: Center(
        child: ElevatedButton(
          onPressed: _launchUrl,
          child: Text('Show Flutter homepage'),
        ),
      ),
    ),
  ),
);

Future<void> _launchUrl() async {
  if (!await launchUrl(_url)) {
    throw Exception('Could not launch $_url');
  }
}

See the example app for more complex examples.

Configuration

iOS

Add any URL schemes passed to canLaunchUrl as LSApplicationQueriesSchemes entries in your Info.plist file, otherwise it will return false.

Example:

<key>LSApplicationQueriesSchemes</key>
<array>
  <string>sms</string>
  <string>tel</string>
</array>

See -[UIApplication canOpenURL:] for more details.

Android

Add any URL schemes passed to canLaunchUrl as <queries> entries in your AndroidManifest.xml, otherwise it will return false in most cases starting on Android 11 (API 30) or higher. Checking for supportsLaunchMode(LaunchMode.inAppBrowserView) also requires a <queries> entry to return anything but false. A <queries> element must be added to your manifest as a child of the root element.

Example:

<!-- Provide required visibility configuration for API level 30 and above -->
<queries>
  <!-- If your app checks for SMS support -->
  <intent>
    <action android:name="android.intent.action.VIEW" />
    <data android:scheme="sms" />
  </intent>
  <!-- If your app checks for call support -->
  <intent>
    <action android:name="android.intent.action.VIEW" />
    <data android:scheme="tel" />
  </intent>
  <!-- If your application checks for inAppBrowserView launch mode support -->
  <intent>
    <action android:name="android.support.customtabs.action.CustomTabsService" />
  </intent>
</queries>

See the Android documentation for examples of other queries.

Web

Some web browsers may have limitations (e.g. a launch must be triggered by a user action). Check package:url_launcher_web for more web-specific information.

Supported URL schemes

The provided URL is passed directly to the host platform for handling. The supported URL schemes therefore depend on the platform and installed apps.

Commonly used schemes include:

Scheme Example Action
https:<URL> https://flutter.dev Open <URL> in the default browser
mailto:<email address>?subject=<subject>&body=<body> mailto:smith@example.org?subject=News&body=New%20plugin Create email to <email address> in the default email app
tel:<phone number> tel:+1-555-010-999 Make a phone call to <phone number> using the default phone app
sms:<phone number> sms:5550101234 Send an SMS message to <phone number> using the default messaging app
file:<path> file:/home Open file or folder using default app association, supported on desktop platforms

More details can be found here for iOS and Android

URL schemes are only supported if there are apps installed on the device that can support them. For example, iOS simulators don't have a default email or phone apps installed, so can't open tel: or mailto: links.

Checking supported schemes

If you need to know at runtime whether a scheme is guaranteed to work before using it (for instance, to adjust your UI based on what is available), you can check with canLaunchUrl.

However, canLaunchUrl can return false even if launchUrl would work in some circumstances (in web applications, on mobile without the necessary configuration as described above, etc.), so in cases where you can provide fallback behavior it is better to use launchUrl directly and handle failure. For example, a UI button that would have sent feedback email using a mailto URL might instead open a web-based feedback form using an https URL on failure, rather than disabling the button if canLaunchUrl returns false for mailto.

Encoding URLs

URLs must be properly encoded, especially when including spaces or other special characters. In general this is handled automatically by the Uri class.

However, for any scheme other than http or https, you should use the query parameter and the encodeQueryParameters function shown below rather than Uri's queryParameters constructor argument for any query parameters, due to a bug in the way Uri encodes query parameters. Using queryParameters will result in spaces being converted to + in many cases.

String? encodeQueryParameters(Map<String, String> params) {
  return params.entries
      .map(
        (MapEntry<String, String> e) =>
            '${Uri.encodeComponent(e.key)}=${Uri.encodeComponent(e.value)}',
      )
      .join('&');
}
// ···
  final emailLaunchUri = Uri(
    scheme: 'mailto',
    path: 'smith@example.com',
    query: encodeQueryParameters(<String, String>{
      'subject': 'Example Subject & Symbols are allowed!',
    }),
  );

  launchUrl(emailLaunchUri);

URLs not handled by Uri

In rare cases, you may need to launch a URL that the host system considers valid, but cannot be expressed by Uri. For those cases, alternate APIs using strings are available by importing url_launcher_string.dart.

Using these APIs in any other cases is strongly discouraged, as providing invalid URL strings was a very common source of errors with this plugin's original APIs.

File scheme handling

file: scheme can be used on desktop platforms: Windows, macOS, and Linux.

We recommend checking first whether the directory or file exists before calling launchUrl.

Example:

final String filePath = testFile.absolute.path;
final uri = Uri.file(filePath);

if (!File(uri.toFilePath()).existsSync()) {
  throw Exception('$uri does not exist!');
}
if (!await launchUrl(uri)) {
  throw Exception('Could not launch $uri');
}

macOS file access configuration

If you need to access files outside of your application's sandbox, you will need to have the necessary entitlements.

Browser vs in-app handling

On some platforms, web URLs can be launched either in an in-app web view, or in the default browser. The default behavior depends on the platform (see launchUrl for details), but a specific mode can be used on supported platforms by passing a LaunchMode.

Platforms that do no support a requested LaunchMode will automatically fall back to a supported mode (usually platformDefault). If your application needs to avoid that fallback behavior, however, you can check if the current platform supports a given mode with supportsLaunchMode before calling launchUrl.