search

e-mission / e-mission-docs

Repository for docs and issues. If you need help, please file an issue here. Public conversations are better for open source projects than private email.
https://e-mission.readthedocs.io/en/latest
BSD 3-Clause "New" or "Revised" License
15 stars 34 forks source link

Permissions errors on Android "Work" devices #1070

Open Abby-Wheelis opened 6 months ago

Abby-Wheelis commented 6 months ago

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 commented 6 months ago

Here's my hack to try to fix it, which was to just flip the error to true https://github.com/e-mission/e-mission-data-collection/commit/1cb376cfa5fe9722e2999354e4061e293ecc5292

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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.

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

shankari commented 6 months ago

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 commented 6 months ago

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

Abby-Wheelis commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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

shankari commented 6 months ago

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 commented 6 months ago

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.

https://github.com/e-mission/e-mission-docs/assets/2423263/01529561-27db-4616-b532-1ae43742d458

shankari commented 6 months ago

@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 commented 6 months ago

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.

https://github.com/e-mission/e-mission-docs/assets/2423263/9111af6a-7c73-4c7b-a6c0-570c40394d7e

Abby-Wheelis commented 6 months ago

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 commented 6 months ago

@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 commented 6 months ago

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 commented 6 months ago

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?