plus_plugins is nine Flutter plugins in one repo, and the support matrix is the real documentation

One repository, nine independent pub.dev packages

The plugin set lives in a single repository but publishes separately. The top level of the tree makes the structure plain: a `packages/` directory, a root `pubspec.yaml`, and a `melos.yaml`, which is the tool that manages a Dart monorepo of this shape. There is also `assets/`, an `analysis_options.yaml`, a `codecov.yml` and an `.editorconfig`.

The nine packages are `battery_plus`, `connectivity_plus`, `device_info_plus`, `network_info_plus`, `package_info_plus`, `sensors_plus`, `share_plus`, `android_alarm_manager_plus` and `android_intent_plus`. The first seven are cross-platform attempts. The last two are explicitly Android only.

The README explains why this repository exists at all. These plugins were developed from plugins that previously existed as part of the Flutter plugins repository, with extra functionality, support for more platforms and better maintenance. So this is a fork-in-spirit of a set of first-party packages, maintained by FlutterCommunity authors, and the split from `flutter/plugins` is the reason a `package_info_plus` exists with that name rather than the older one.

Each plugin has its own README and its own source link in the table of contents, so the packages are independent in documentation as well as in distribution. The plugin list in the README is a catalogue, not an aggregate library; nothing in the structure suggests these are meant to be imported together.

The platform tables disagree, and that is the useful part

Every plugin in the README carries a six-column support table covering Android, iOS, macOS, Web, Linux and Windows. For most plugins every cell is a check mark. For two of them it is not, and those two rows are the reason to read the tables rather than the descriptions.

`network_info_plus` covers Android, iOS, macOS, Linux and Windows, but the web column is empty. That is a gap you will hit if your app has a web target and expects to enumerate networks.

`sensors_plus` is the narrower one. It gives Android, iOS and Web as supported, with macOS, Linux and Windows all unsupported. The plugin itself is described as accessing accelerometer, gyroscope, magnetometer and barometer sensors, and the table marks the listed desktop targets as unsupported.

That combination matters for anyone shipping a Flutter app across desktop and mobile, which is the case the Flutter plugin ecosystem usually targets. Your platform-conditional code will not be one branch. It will be a branch per plugin, and the branches will not be the same branch.

The two Android-only plugins have a one-column table rather than six, which is an honest way to say there is nothing else to report: `android_alarm_manager_plus` accesses the Android AlarmManager service and runs Dart code in the background when alarms fire, and `android_intent_plus` launches Android Intents and is stated as not supported on iOS.

What each plugin actually gets you, in one sentence each

The feature descriptions are terse, which makes the differences between neighbours easier to see than they would be in longer prose.

`battery_plus` reports battery state, named as full, charging and discharging. `connectivity_plus` discovers the state of the network, described as WiFi and mobile or cellular connectivity on Android and iOS, even though its table also claims macOS, Linux, Windows and web support. That gap between the sentence and the table is worth noticing: the description documents the two platforms it was written against first, the table claims more.

`device_info_plus` gives detailed device information, make and model, plus the Android or iOS version the app is running on. `package_info_plus` is the application rather than the device, querying package information such as CFBundleVersion on iOS or versionCode on Android. `network_info_plus` is described only as discovering network info, which is thin enough that the README's own per-plugin README link is the place to get details.

`share_plus` is the most specific of the set, because it names the mechanism on each platform: the platform share UI, implemented with the ACTION_SEND intent on Android and UIActivityViewController on iOS. If you need to know which native path is being used, that is the one documented in the repository itself.

`android_alarm_manager_plus` is the only plugin here that runs your Dart code later, in the background, triggered by the platform alarm scheduler.

Installation goes through pub.dev, and the README gives no command

The README contains no install command and no Dart configuration snippet. Each plugin links to its own page on pub.dev through the badge references at the bottom, so the documented route to any plugin is that package page rather than anything in this repository.

That is a real gap for a catalogue article. In a Dart project, a plugin is declared as a dependency in `pubspec.yaml` by name and version constraint, and a platform-specific implementation is often configured in the native project files, such as Gradle or the iOS Podfile. None of that appears here, and inventing a version number would be worse than saying nothing. Read the per-plugin page for the constraint that matches the Flutter SDK in use.

For contributors, the workflow is documented in a different way. Changes go through the contribution guide at CONTRIBUTING.md and a pull request, and the README asks for both feedback and pull requests. There is a GitHub Actions workflow whose query filter is `all_plugins`, which is the badge at the top of the README, so continuous integration runs across the whole set rather than per plugin.

The repository also carries CODE_OF_CONDUCT.md and a codecov configuration, and the README's Status section says plainly that issues are answered by maintainers and other community members on a best-effort basis. That sentence is the honest summary of the support model for the entire collection.

Where to file an issue decides how fast you get an answer

The Issues section splits reporting into two destinations, and using the wrong one is the most common reason a question goes unanswered.

PlusPlugins-specific issues, bugs and feature requests go in this repository's issue tracker. Anything that is not specific to these plugins goes to the Flutter issue tracker instead. The distinction is about whether the fault lies in the community plugin or in the Flutter framework it is built on.

In practice that means a sensor returning no events on a desktop build, where the table says the platform is unsupported, is not a bug report at all. It is a documented gap, and filing it as a bug will produce a response pointing at the table. Whereas a share sheet failing to appear on a platform the table marks supported is a genuine report.

There is a related point about versioning. The release tags visible for this repository are from 2022, including `share_plus-v6.3.0` and `package_info_plus-v3.0.2`, both dated 2022-11-14, with `share_plus-v6.2.0` shortly before. Yet the repository itself is not archived and the last push was on 2026-10-14, and the source tree is organised for continuous multi-package release through melos.

So the tag history is not a reliable guide to whether a package is maintained. The current versions of each plugin are on its pub.dev page, and the per-plugin README is where API changes will be described. The repository is BSD-3-Clause licensed, which is permissive but carries copyright, disclaimer and endorsement conditions.

Editorial conclusion

plus_plugins suits a Flutter application that needs one or two device capabilities and wants a community-maintained package rather than an in-house platform channel, because each plugin ships separately, so a project needing only package_info_plus does not pull in the rest. It is the wrong choice for sensors on desktop, for network_info_plus on the web, and for anything where the Android-only pair would force a platform branch into shared code. Before picking a plugin from this repository, read its support table rather than the feature sentence, since the tables are not uniform and `sensors_plus` covers Android, iOS and the web but not macOS, Linux or Windows; then confirm the package version published on pub.dev matches the one your lockfile expects, because the release tags visible here date from 2022 while the repository itself was pushed to on 2026-10-14.

Frequently asked questions

Official sources

1. fluttercommunity/plus_plugins on GitHub
2. Issues
3. License: BSD-3-Clause
4. README
5. Releases