Skip to content

Feature/permission request on start#62

Open
lagerspetz wants to merge 4 commits intomasterfrom
feature/permission-request-on-start
Open

Feature/permission request on start#62
lagerspetz wants to merge 4 commits intomasterfrom
feature/permission-request-on-start

Conversation

@lagerspetz
Copy link
Copy Markdown
Member

Permission request to block user from using Carat before all necessary permissions are granted.
@jhamberg can you check if this works on a new user's device properly? My Huawei is currently testing a proper fix to #61 .

perms if not granted every time the app would refresh.
@lagerspetz lagerspetz requested a review from jhamberg May 17, 2019 03:17
@lagerspetz
Copy link
Copy Markdown
Member Author

This is missing the permissions rationales still:
https://developers.google.com/android/guides/permissions

Copy link
Copy Markdown
Member

@jhamberg jhamberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With your changes the application keeps prompting the Location and Telephony permissions. If you hide these with "Don't show again" then the following "Ignore Battery Optimizations" dialog will not work and instead force closes the application regardless of the choice clicked. Revoking permissions after they have been given also leads to a crash.

Doing a clean run (that is, accepting everything) seems to work fine.

@lagerspetz
Copy link
Copy Markdown
Member Author

I want to in effect force these permissions to be accepted. READ_PHONE is used for UUID to make carat id collisions less likely, and location is used for moved distance calculation, so these should always be available.

@jhamberg
Copy link
Copy Markdown
Member

jhamberg commented May 17, 2019

I agree, those permissions are definitely needed (cannot trust SecureRandom to be implemented properly on all versions of Android). Perhaps we could initially request all permissions and then check for shouldShowRequestPermissionRationale on the callback which should return false if the user has hidden the prompt. If so, we can show a dialog taking them to the settings menu.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants