# CARP Flutter plugins wrap phone sensors for research apps > carp-dk/flutter-plugins is a collection of first party Flutter plugins from the CARP team at the Technical University of Denmark, covering pedometer steps, noise levels, screen state, ambient light, app usage, notifications, weather, air quality, audio streams, location and a family of wearable sensors. The value is a sensor layer you can point a study app at, and the cost is that the plugins are maintained by a small academic group with limited resources. **carp-dk/flutter-plugins** — A collection of Flutter plugins maintained by the CARP team - Repository: https://github.com/carp-dk/flutter-plugins - Stars: 609 · Forks: 731 - Language: Dart - License: not declared - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/carp-dk-flutter-plugins ## A sensor layer assembled for study apps, not a general purpose SDK The repository holds the source for Flutter first party plugins maintained by the Copenhagen Research Platform team at the Technical University of Denmark, and the packages directory contains every plugin in the collection. The plugins cover a specific and fairly unusual set of capabilities: pedometer for step events, noise_meter for a decibel reading, screen_state for screen state changes, light for ambient light sensor readings, app_usage for tracking usage of all applications on the phone, notifications for tracking device notifications, audio_streamer for streaming microphone audio as PCM, and carp_background_location for tracking location while the app is in the background. There are also two that reach out to third party services rather than the phone itself. weather fetches current weather and forecasting through the OpenWeatherMap API, and air_quality returns an air quality index from the WAQI API. Those two are thin wrappers around a network service, which makes them a different kind of dependency from the sensor plugins even though they sit in the same table. The through line is that this is a collection rather than a framework. There is no shared base class or common architecture described in the README, only a set of independent packages. A team picks the ones it needs. The repository also contains an ios-applications directory and a .zed directory, and it is hosted under the carp-dk organisation while its issue tracker and contribution guide point at the cph-cachet organisation, a detail worth remembering when you go looking for where to file something. ## Platform channels are how every one of these plugins reaches the hardware The README states the mechanism plainly: Flutter plugins enable access to platform-specific APIs using a platform channel, and it points at the official Flutter documentation for how plugins are used. That is the entire technical model, and it is the reason these plugins are thin. A Dart side declares the API and the method channel, and the native Android and iOS code does the actual work: talking to the sensor APIs, requesting permissions, and streaming results back. The consequence is that every plugin carries two native implementations plus the Dart bridge, and each one is bound to whatever the platform SDK offered at the time it was written. A plugin that wraps the pedometer sensor is, in effect, a thin layer over the platform's own step counter, so its behaviour on a given device is the platform's behaviour with a little translation applied. This also explains why the platform support column in the table matters so much. Where a plugin is Android only, it is because the underlying capability has no iOS counterpart worth exposing, or because nobody wrote the Swift side. Either way, the choice is fixed at the repository level and not something an app developer can work around without maintaining a fork of the plugin itself. ## The sensor plugins, grouped by what they actually read Reading the table by category is more useful than reading it row by row. Motion and position are the largest group. pedometer collects step events, carp_background_location tracks location even when the app is in the background, and mobility_features computes daily mobility features from location data, which is a layer above raw position rather than a sensor wrapper. The background location plugin in particular implies foreground service behaviour and the battery cost that comes with it on Android. Audio and environment form the next group. noise_meter reads the noise level in decibels, audio_streamer streams audio as PCM from the microphone, and light tracks light sensor readings, which on many phones is an ambient light sensor rather than anything that measures visible brightness. Device and app state covers screen_state for screen state changes, app_usage for tracking usage of all applications on the phone, and notifications for tracking device notifications. The last two are the invasive ones from a permissions and privacy standpoint, since both expose data about the rest of the user's phone rather than about the user themselves. Finally there is the wearable cluster. movisens_flutter handles Movisens sensor communication, esense_flutter covers the eSense ear sensor, empatica_e4link targets the Empatica E4, and movesense_plus handles Movesense sensor communication. activity_recognition sits alongside them and covers activity recognition. These are the plugins that make the collection interesting, and also the ones that carry the most device specific risk. ## Publishing status is uneven across the packages The pub.dev column of the table is where the collection shows its seams. Most plugins link to a pub package, which means they can be pulled into a Flutter project the ordinary way. Two are exceptions in different ways. empatica_e4link is marked not published, so there is no pub.dev package for it in the table. Anything using that plugin has to depend on it from source or from a local path, which is a different and much less comfortable dependency model for a published app. flutter_foreground_service is marked DISCONTINUED in bold, and it is Android only. The table still links a pub package for it, which means an existing dependency can keep resolving, but a project that wants a maintained foreground service should not pick it. The package directory name in the link is flutter_foreground_service, matching the package name, so there is no naming puzzle to solve there. The links point at pub.dartlang.org package pages rather than pub.dev directly, which is the older domain for the same registry and worth knowing if you follow one of them from a script. Because these plugins live in one repository but ship separately, the practical implication is that a plugin can be deprecated or discontinued without the rest of the collection changing. Version numbers and support status live per package, not per repo. ## Adding a plugin to a Flutter project The README does not contain an installation section or a command for adding a plugin, and the repository publishes no GitHub releases, so there is nothing to download from a release page. The intended path is the package registry: the table links each plugin to its pub package, and the repository itself carries a .gitattributes file, a .github directory, a .gitignore and a .zed directory at the top level alongside packages. For an app developer the practical route is therefore to add the dependency by its published package name from pub.dev, for example screen_state, pedometer or noise_meter, and to consult the individual plugin's own README under the packages directory for its API, its permissions and its platform requirements. The root README is an index, not API documentation, and it says nothing about permissions, minimum SDK versions or event formats. That last point is the one to get right before writing code. Each plugin wraps a different platform API with its own permission requirements and its own callback shape, and none of that detail is in the root README. Reading ten package READMEs is the actual cost of adopting this collection, and it is a cost the maintainers acknowledge in a different way when they ask for help. One more path exists for the sensors that need a companion app. The repository contains an ios-applications directory, which suggests that at least some of the wearable integrations require a native iOS application alongside the plugin, something a pure Flutter project cannot avoid. ## Maintenance is a stated constraint, not a hidden one The contributing section is unusually direct about the project's capacity. It says the CARP team has limited resources for maintaining these plugins and relies on outside help, and it welcomes contributions ranging from small documentation corrections to bug fixes to large feature enhancements or new features in a plugin. That framing is the most useful thing in the README for an adopter, because it tells you what kind of dependency this is. These are research outputs from an academic group, published so that other researchers can build on them, and the maintenance model is participation rather than a support contract. The dates support the same reading. The last push was on 2026-09-16 and the repository has no GitHub releases at all, so there is no tag stream to pin against and no changelog to read. Per package versioning on pub.dev is the only version history available, and the root repository's licence field is reported as unknown, so the terms for reusing the code are not stated anywhere in the project documentation. Each package directory would need to be checked for its own licence file before you copy code out of it. If your application needs a maintained platform sensor layer with a stated support commitment, that is not what this repository offers, whatever its code quality. ## Where this collection is the wrong answer There are three cases where reaching for these plugins is a mistake. The first is a consumer app with no research purpose. Screen state, app usage and notification tracking exist here because a study needs to know when a participant picked up the phone or which other apps they used. If your product does not need that, the permission prompts alone make these plugins the wrong choice, and the maintainers say so by asking for outside help to sustain them. The second is a platform your plugin does not cover. app_usage, notifications, light and empatica_e4link are Android only in the table, and the wearable integrations vary by device vendor. A Flutter project targeting both platforms has to feature-detect and ship a different code path, and there is no abstraction layer in this repository to hide that. The third is anything requiring guarantees about long term availability. The discontinued foreground service plugin shows what happens to a package in this collection when upstream platform changes make it unmaintainable. There is no notice mechanism, no release history at the repository level and no compatibility promise, so the risk of adopting a sensor plugin is that it silently stops working when the platform SDK beneath it moves. The alternative for most teams is the first party plugin ecosystem that ships with Flutter itself for the common capabilities, or writing a thin channel implementation directly against the platform APIs when the specific sensor is not covered, which is also how several of these plugins were written in the first place. ## Conclusion CARP Flutter plugins fit research and health app developers who need raw sensor streams from consumer phones and wearables without writing the Android and iOS channel code themselves, and who want the same interface across screen_state, pedometer, noise_meter, audio_streamer and the wearable plugins. They are the wrong choice for a commercial app that needs a long term maintenance commitment from a vendor, since the project states plainly that the team has limited resources and asks for outside help. Verify three things before building on them: that the plugin you need supports the platform you target, because the repository lists light, app_usage, notifications, empatica_e4link and flutter_foreground_service as Android only while the rest cover both; that the package is on pub.dev, which empatica_e4link is not; and that you read the README of the individual package under packages, because the root README carries no API documentation. The last push was on 2026-09-16 and the repository publishes no GitHub releases. ## FAQ ### Which platforms does the CARP Flutter plugins collection support? Most plugins support both Android and iOS, including screen_state, pedometer, noise_meter, weather, air_quality, movisens_flutter, esense_flutter, movesense_plus, activity_recognition, audio_streamer, mobility_features and carp_background_location. light, app_usage, notifications, empatica_e4link and flutter_foreground_service are listed as Android only. ### How do I add a CARP Flutter plugin to my project? The README does not give an install command and the repository publishes no GitHub releases. Each plugin except empatica_e4link links to a pub package, so the dependency is added by its published package name from pub.dev, and the API details are in the individual package README under the packages directory. ### Which plugins in carp-dk/flutter-plugins are discontinued or unpublished? flutter_foreground_service is marked DISCONTINUED and is Android only. empatica_e4link is marked not published on pub.dev, so it has to be depended on from source rather than from the registry. ### Do these plugins need background location or foreground service on Android? carp_background_location tracks location even when the app is in the background, and flutter_foreground_service was an Android foreground service plugin, although it is now marked discontinued. The root README does not document the permission requirements for any plugin. ### Who maintains the CARP Flutter plugins and how active are they? They are maintained by the Copenhagen Research Platform team at the Technical University of Denmark, which states that it has limited resources for maintaining the plugins and relies on outside help. The last push was on 2026-09-16 and the repository has no GitHub releases, so there is no tag stream to pin against. ## Sources - [carp-dk/flutter-plugins on GitHub](https://github.com/carp-dk/flutter-plugins) - [Issues](https://github.com/carp-dk/flutter-plugins/issues) - [README](https://github.com/carp-dk/flutter-plugins/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/carp-dk-flutter-plugins