Manage unnecessary permission data for android

[klnfreedom]

This pull request introduces improved permission handling for health data retrieval on Android and adds support for capturing the raw workout activity type in the Dart data model. The main changes are grouped into Android permission checks and Dart model enhancements.

Android permission checks:

• Added a new HealthPermissionChecker class to encapsulate permission checks for location, distance, calories burned, and steps in HealthPermissionChecker.kt.
• Updated HealthDataReader.kt to use HealthPermissionChecker before attempting to read workout distance, calories burned, and steps; if permissions are missing, the retrieval is skipped and a log message is recorded. [1] [2] [3] [4] [5]
• Changed error handling in HealthDataReader.kt to return a proper error result when data is unavailable, instead of returning null.

Dart model enhancements:

• Added a new rawWorkoutActivityType field to the WorkoutHealthValue class in health_value_types.dart, storing the raw activity type from native data. Updated the constructor, factory, toString, equality, and hashCode methods to support this new field. [1] [2] [3] [4]

[marcos-abreu]

Hi @klnfreedom,

I’m fairly new to the health package and Flutter, so please excuse me if I’m missing something obvious.

I noticed this PR introduces permission checks using ContextCompat and PackageManager, while the Health Connect documentation (and the current implementation in this plugin) uses HealthPermission together with permissionController.getGrantedPermissions().

Could you explain the motivation for using the Android-level checks instead of (or in addition to) the Health Connect API approach?

[iarata]

@klnfreedom Thanks for the PR!
We were in the process of moving the health package to its own repo and could you please send your PR to the https://github.com/carp-dk/carp-health-flutter?

[klnfreedom]

Hi @klnfreedom,

I’m fairly new to the health package and Flutter, so please excuse me if I’m missing something obvious.

I noticed this PR introduces permission checks using ContextCompat and PackageManager, while the Health Connect documentation (and the current implementation in this plugin) uses HealthPermission together with permissionController.getGrantedPermissions().

Could you explain the motivation for using the Android-level checks instead of (or in addition to) the Health Connect API approach?

We do not request Android-level Health permissions (e.g., android.permission.health.READ_STEPS, ACCESS_FINE_LOCATION) unless the Dart layer explicitly requests the corresponding types.

Previously, native code would probe steps/distance unconditionally, throwing an error on Android when the app hadn’t declared extra manifest permissions. That error bubbled to Dart and looked like a failure, effectively forcing developers to add Android permissions they don’t need — which in turn triggers extra Play Console checks.

Now we gate native checks by the Dart request and gracefully no-op for non-requested types (no crash, no manifest requirements, no extra Play Console declarations).

Result: if an app only asks for, say, heart rate or workouts, it won’t see native probes for steps/distance/location, won’t need extra manifest permissions, and won’t fail at runtime.

[klnfreedom]

@klnfreedom Thanks for the PR! We were in the process of moving the health package to its own repo and could you please send your PR to the https://github.com/carp-dk/carp-health-flutter?

carp-dk/carp-health-flutter#449
Done.