fix: now correctly returns write exercise route permission if it is granted

[ugurakin1]

Context

We were not returning any indication as to whether HealthPermission.PERMISSION_WRITE_EXERCISE_ROUTE was included in the granted permissions or not prior to this PR. After the PR we correctly return a JS entry for the write ExerciseRoute permission:

Granted permissions  {"permissions": [{"accessType": "read", "recordType": "CyclingPedalingCadence"}, {"accessType": "write", "recordType": "CyclingPedalingCadence"}, {"accessType": "read", "recordType": "ExerciseSession"}, {"accessType": "write", "recordType": "ExerciseSession"}, {"accessType": "read", "recordType": "StepsCadence"}, {"accessType": "write", "recordType": "StepsCadence"}, {"accessType": "read", "recordType": "Steps"}, {"accessType": "write", "recordType": "Steps"}, {"accessType": "write", "recordType": "ExerciseRoute"}]}

cc: @matinzd

[gemini-code-assist]

Hello @ugurakin1, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

Summary of Changes

Hello! Gemini here, providing a summary of this pull request to help everyone get up to speed quickly.

The primary goal of this PR, as indicated by the title and description, is to fix an issue where the PERMISSION_WRITE_EXERCISE_ROUTE was not being correctly included in the list of granted permissions returned by the getGrantedPermissions function. Previously, even if this permission was granted by the user, the application layer would not receive an indication of it.

This change addresses the issue by explicitly checking for the PERMISSION_WRITE_EXERCISE_ROUTE in the set of granted permissions received from the native Health Connect API. Since ExerciseRoute is not treated as a standard record type in the same way as others (like Steps or ExerciseSession), its write permission needs to be handled separately and added manually to the list of permissions returned to the JavaScript/TypeScript layer. Corresponding type definitions in the TypeScript files have also been updated to reflect that the returned permission list can now include the WriteExerciseRoutePermission type.

Highlights

• Bug Fix: Exercise Route Write Permission: Fixes a bug where the PERMISSION_WRITE_EXERCISE_ROUTE was not being reported as granted, even when it was.
• Android Implementation: Adds specific logic in the Android native code (PermissionUtils.kt) to check for and include the PERMISSION_WRITE_EXERCISE_ROUTE in the returned permission list, separate from the standard record type permissions.
• TypeScript Type Updates: Updates the TypeScript definitions (NativeHealthConnect.ts, index.tsx) for permission-related functions (requestPermission, getGrantedPermissions) to correctly include WriteExerciseRoutePermission as a possible type in the returned array.

Changelog

• android/src/main/java/dev/matinzd/healthconnect/permissions/PermissionUtils.kt
  • Added a comment explaining the loop for adding read/write permissions for record types (Line 43).
  • Added a new code block to manually check for and add the PERMISSION_WRITE_EXERCISE_ROUTE to the result array if it is present in the granted permissions (Lines 57-60).
  • Added a comment explaining why ExerciseRoute is handled separately (Line 57).
• src/NativeHealthConnect.ts
  • Updated the return type of the requestPermission method in the Spec interface to include WriteExerciseRoutePermission (Line 32).
  • Updated the return type of the getGrantedPermissions method in the Spec interface to include WriteExerciseRoutePermission (Lines 34-36).
• src/index.tsx
  • Updated the return type of the exported requestPermission function to include WriteExerciseRoutePermission (Line 107).
  • Updated the return type of the exported getGrantedPermissions function to include WriteExerciseRoutePermission (Lines 115-117).

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

---

A permission missed,
A route not listed,
Now the code is fixed,
With types correctly mixed.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request successfully addresses the issue of not returning the HealthPermission.PERMISSION_WRITE_EXERCISE_ROUTE status when it is granted. The changes involve updating the Kotlin native code to include this permission in the results and modifying the TypeScript type definitions to accurately reflect this new behavior. The solution is well-targeted and the code is generally clear. One suggestion for improving maintainability in the Kotlin code has been provided.

Summary of Findings

• Use of String Literal for Record Type: In PermissionUtils.kt, the string literal "ExerciseRoute" is used directly. Defining this as a constant would improve maintainability, especially since it's used in another part of the class (parsePermissions). A review comment has been added for this (medium severity).
• Clarity of Comment in Kotlin Code: In PermissionUtils.kt (line 57), the comment // ExerciseRoute isn't a record type, so we need to add it manually could be slightly more precise. While understandable in context, ExerciseRoute is treated as a record type string from the JavaScript/React Native perspective. A more accurate phrasing might be something like // PERMISSION_WRITE_EXERCISE_ROUTE is a special permission not derived from a standard Record KClass, handle explicitly. This is a minor point (low severity) and was not added as a direct review comment due to the current review settings focusing on medium severity and above.
• TypeScript Type Updates: The TypeScript type definitions in src/NativeHealthConnect.ts and src/index.tsx have been correctly updated to include WriteExerciseRoutePermission in the return types of requestPermission and getGrantedPermissions. This aligns with the native code changes and accurately reflects the possible returned permission types.

Merge Readiness

This pull request effectively addresses the described issue and the core logic changes are sound. The TypeScript updates are consistent and correct.

There is one medium-severity suggestion for the Kotlin code in PermissionUtils.kt concerning the use of a string literal, which could be refactored into a constant to improve maintainability and reduce the risk of inconsistencies.

I recommend that this suggestion be considered and ideally addressed before merging to ensure the highest code quality. As an AI reviewer, I am not authorized to approve pull requests; this decision rests with the designated human reviewers after considering this feedback.

[ugurakin1]

@matinzd we've merged this in our fork so nothing urgent on our side but would be good to get out either way. Let me know if I can help in any way 👍

[matinzd]

Can you rebase this with the main branch?