Permissions errors on Android "Work" devices

[Abby-Wheelis]

As the GSA project is asking people to install OpenPATH onto their work phones for Beta testing, we are getting reports of users unable to pass the Permissions screen due to the "unused app" permission.

This permission is "grayed out" in their settings (see screenshot) which we believe based on these docs (app hibernation exception) to be related to the nature of the work profile..." If your app falls into one of the following categories, it is exempt from the app usage standards and will not hibernate. ... Any app that a user installs on a work profile
. Note that if the same app also resides on a personal profile, only the work profile app is exempt."

From internal discussion: "Because the feature is bypassed, it is grayed out in the UI and getUnusedAppRestrictionsStatus() returns ERROR. Our code currently treats ERROR as lacking the permission which is why the check is stuck at red."

@shankari can you provide context here on what fix was already tried? I think our original thought was that it was configured as a work profile, but from my conversations with someone at dfc this week, I don't think it's a separate profile, but maybe the phone is just configured as a work phone?

[shankari]

Here's my hack to try to fix it, which was to just flip the error to true
e-mission/e-mission-data-collection@1cb376c

Note that I wasn't able to test it, and I don't think that anybody else tested it either.

@louisg1337 can you please try to test this? Once we know why it is happening, I anticipate that the fix will be fairly simple.
To test: it looks like there is a sample app that will at least let us test this out in the emulator https://developer.android.com/codelabs/work-profile-apps#0

We can follow those instructions to create a dummy work profile and install OpenPATH in it, which should allow us to see what is going on with this function.

Also asking them to send their logs since that will also give us a clue about what is going on

[Abby-Wheelis]

Also asking them to send their logs since that will also give us a clue about what is going on

Will they be able to send logs if they can't get logged in? Since the error is during onboarding I'm not sure that they can get to the profile to export logs

[shankari]

That's an excellent point. However, we are the the maintainers of this code, and we are beta testing this functionality, so we can hack away. Concretely, we can skip the unused permission check for DFC Fermata. It won't affect anybody else, and that will allow them to go further, start testing and send us logs.

[louisg1337]

Work Profile Bug Update

Solution
I've managed to get a PR together that fixes the permissions issue described above. The solution ended up being adding in a check in SensorControlChecks.checkUnusedAppsUnrestricted() that checks to see if the app is installed on a work profile or not. If it is installed on one, we immediately return true which then returns a cordovaCallback.success, and if not we continue the checks like normal. In that case, the Unused apps disabled check now automatically turns green on work profiles which unblocks the user.

Android Bug?
Shankari made a great point in her commit comment with how PackageManagerCompat.getUnusedAppRestrictionsStatus(ctxt); should return FEATURE_NOT_AVAILABLE or DISABLED as they accurately describe the work profile hibernation exemption we are experiencing.

I was curious to see what other devices were returning for that function while in a work profile, and I saw the following.

• Pixel | API 33 returns API_31
• Motorolla | API 28 returns API_30_BACKPORT
• GSA User's Phone (unknown API) returns API_31

So it definitely seems like something is awry here and it may be worth filing that issue against Google to bring it to their attention. For the time being, however, we do have a workaround in place which works fine.

Reverting Past Fixes

• I reverted the change to e-mission-phone in this PR.
• I also reverted the change to e-mission-datacollection in my PR with the work profile check.

[shankari]

So it definitely seems like something is awry here and it may be worth filing that issue against Google to bring it to their attention. For the time being, however, we do have a workaround in place which works fine.

Yes, let us please do this. When I have found issues with android documentation being incorrect in the past, I have not hand the time to report it. But now we do have the time to do it, and you also get to tell Google that they are wrong, which might be a fun experience.

[louisg1337]

Just submitted the issue to Google, lets hope it gets fixed!

[Abby-Wheelis]

Do we expect this to be working right now? In the training, an android user was unable to pass through the permissions due to this same issue. I checked and the app version was the most recent one available in the store.

[shankari]

I promoted 1.7.7 to production last night. Don't tell me it broke this. It shouldn't have!
Let me double-check...

[shankari]

no, that code is definitely still in the current version. Let me check the config...
If the config is messed up, it would also explain why all of Leidy's trips were tracked...

[shankari]

config also seems to be fine, but double-checking that we didn't move things around somewhere by mistake

[shankari]

config seems to be fine too

>>> parsed_config = json.load(open("configs/dfc-fermata.nrel-op.json"))
>>> parsed_config['tracking']
{'bluetooth_only': True}

What the heck! Trying to reproduce now...

[shankari]

EDIT: Verified that I can reproduce from the current version. Debugging now...

Verified that I cannot reproduce from the current version (I was mistaking "ignore battery optimizations" for the check that we wanted to ignore). As you can see in the video below, we don't show the "unused app restriction" for the DFC Fermata use case.

Screen.Recording.2024-05-21.at.12.54.19.PM.mov

[shankari]

@Abby-Wheelis can you double check that the person logged in using a DFC Fermata opcode and not "open access" or something? In a prior program, we had a prior participant log in to open access after seeing it in the participant guidelines.

[shankari]

Installed from google play, verified version 1.7.7, still works.
@Abby-Wheelis did they have the bluetooth permission enabled? Because my bet right now is that they used the token for a different study or program.

trimmed_working_on_177_google_play.mov

[Abby-Wheelis]

can you double check that the person logged in using a DFC Fermata opcode and not "open access" or something

The user is Darius, who had encountered this issue before. I just confirmed via email that he was using the correct opcode. As far as the bluetooth permission goes, I don't remember seeing that specifically, I just saw the grayed out permission and knew that was something that had been an issue, and he recognized the behavior as well since he had been one of the testers as well.

[shankari]

@Abby-Wheelis Are you telling me that this worked for Darius earlier and it is not working now?

1. I am not able to reproduce
2. this is a super easy (one-line) fix
3. Are any other android users encountering this? Notably, Rod confirmed that the app worked for him earlier, is he seeing the same issue?

[Abby-Wheelis]

Are any other android users encountering this? Notably, Rod confirmed that the app worked for him earlier, is he seeing the same issue?

He was the only android user in the meeting, Rod is out of the office, so I don't know if he has/will encounter this

[Abby-Wheelis]

Heard back from the user this AM. From the screenshots, it looks like the only issue is that he has not enabled notifications, I replied with instructions to enable notifications and waiting to hear if that worked.

I think what happened in the meeting is he just saw the grayed out permission and assumed the problem was happening again, and I failed to investigate throughly enough in the moment. I'll reply to this thread once I confirm if that was the only issue. I've added some text to the slide deck that I presented (and is attached to the meeting invite so people who didn't make the meeting can reference it) explaining in words how to enable the permissions in case that could help this from being a sticking place in the future. I'm wondering now if completing the onboarding process myself while screensharing from a phone would have been better ... I used the same slides I used for the onboarding meeting in Laos since it seemed to work well there, but maybe I should try "live demo" for the virtual onboarding on Thursday?