| commit | c5349bc9a5be1cbef9c13571d9d6d2b506240b20 | [log] [tgz] |
|---|---|---|
| author | stuartmorgan <stuartmorgan@google.com> | Thu Jan 11 20:27:39 2024 -0800 |
| committer | GitHub <noreply@github.com> | Fri Jan 12 04:27:39 2024 +0000 |
| tree | e818edc44f4887731097ce0ccc8c88ef4eea452a | |
| parent | b61735b00e3bea04e8a3dc8b8f5e980de9cb07cd [diff] |
[various] Add iOS privacy manifests (#5846) Adds privacy manifests to all iOS plugins. While we only *need* to do the plugins listed [here](https://developer.apple.com/support/third-party-SDK-requirements/) for now, the wording of the page: > The following are commonly used SDKs in apps on the App Store suggests that the list of things for which this is required is just an arbitrary cutoff rather than a conceptual distinction, so it seems safest to just assume the list will grow over time and do all of them. To ensure that, this includes new repo tooling to check that a manifest is specified in the podspec. The large caveat is that we do not currently know if this actually works. This is the method of inclusion that seems to be [the consensus among people using Cocoapods](https://github.com/CocoaPods/CocoaPods/issues/10325), as bundling it directly as a `resource` causes problems for clients who do not use `use_frameworks`. (In theory it seems like a manifest would not actually be *required* in that case since there is no framework, but it has the potential to actually stomp top-level resources.) Hopefully the automated analysis that Apple will eventually roll out will tolerate the file being bundled in a resource bundle in the framework rather than a top-level manifest file. If not, however, it's not clear how Cocoapods can be supported, so we can adopt this common approach for now under the assumption that eventually tooling will adapt to the reality of the ecosystem, and revisit the exact bundling later if necessary. Only `shared_preferences` has a non-empty manifest, as it is our only plugin that uses a required reason API, and none of our plugins themselves collect private data. Ideally for that plugin we would instead use `C56D.1`, which is for wrappers, but as currently written we can't use it since it's exclusively a wrapper. If that changes in the future based on our pending request, we can revisit. For now, however, this reason should suffice since we don't currently allow reading from other app groups. Fixes https://github.com/flutter/flutter/issues/131495 Fixes https://github.com/flutter/flutter/issues/139756 Fixes https://github.com/flutter/flutter/issues/139757 Fixes https://github.com/flutter/flutter/issues/139758 Fixes https://github.com/flutter/flutter/issues/139759 Fixes https://github.com/flutter/flutter/issues/139760 See also https://github.com/flutter/flutter/issues/139761
This repo is a companion repo to the main flutter repo. It contains the source code for Flutter's first-party packages (i.e., packages developed by the core Flutter team). Check the packages directory to see all packages.
These packages are also available on pub.
Please file any issues, bugs, or feature requests in the main flutter repo. Issues pertaining to this repository are labeled “package”.
If you wish to contribute a new package to the Flutter ecosystem, please see the documentation for developing packages. You can store your package source code in any GitHub repository (the present repo is only intended for packages developed by the core Flutter team). Once your package is ready you can publish to the pub repository.
If you wish to contribute a change to any of the existing packages in this repo, please review our contribution guide, and send a pull request.
These are the packages hosted in this repository:
