Skip to content
This repository has been archived by the owner on Jun 20, 2023. It is now read-only.

Improve UX for disabling battery optimization #1606

Closed
3 tasks done
timokau opened this issue Nov 14, 2020 · 8 comments
Closed
3 tasks done

Improve UX for disabling battery optimization #1606

timokau opened this issue Nov 14, 2020 · 8 comments
Assignees
Labels
enhancement Improvement of an existing feature mirrored-to-jira This item is also tracked internally in JIRA UX Issue related to UX aspects

Comments

@timokau
Copy link

timokau commented Nov 14, 2020

Avoid duplicates

  • This enhancement request has not already been raised before (to the best of my knowledge, it's a bit hard to search for)
  • Enhancement request is specific for Android only, for general issues / questions that apply to iOS and Android please raise them in CWA-Wishlist
  • If you are proposing a new feature, please do so in CWA-Wishlist

Current Implementation

Currently, corona-warn

  • explains why battery optimization should be disabled and why that is okay
  • suggests that the user disables it
  • forwards the user to the settings if they chose to do so.

The problem is with the last step. It just leaves the user in the "battery optimization" setting, which by default just shows a list of apps that does not even include the Corona-Warn app (at least for me). You then have to chose "all apps" and search for Corona-Warn in a long list. Then you can finally select it and disable battery optimization.

I think this can be confusing for the user and might prevent them from disabling the battery optimization and/or leave them a bit confused.

Suggested Enhancement

If I remember correctly, the syncthing-android app was able to directly prompt me to disable battery optimization for that app. I just had to approve it, and it was done. Similar to a normal permission prompt. Corona-Warn should do it the same way.

Edit: For reference

  • Here is how synthing implements it.
  • Here is the relevant android documentation.

Expected Benefits

More users will disable battery optimization and get warnings on time. As a "softer" benefit, more users will have a good first impression in the app (instead of feeling slightly confused and unsure if they might have messed up something when setting it up).


Internal Tracking ID: EXPOSUREAPP-3835

@timokau timokau added the enhancement Improvement of an existing feature label Nov 14, 2020
@heinezen
Copy link
Member

Hello @timokau

Thank you for the suggestion. I have created a ticket in the internal Jira for your request (ticket ID: EXPOSUREAPP-3835) where it will now be discussed by the developers. They will decide how and when this change will be implemented. We will notify everyone here on Github if we get any news about the implementation progress of this request.

Best Regards,
CH


Corona-Warn-App Open Source Team

@MikeMcC399
Copy link
Contributor

Note: I know that background exposure checking has been an ongoing issue to get it to work reliably on all Android devices, and I assume that the current implementation is the best compromise at this time.

But in any case, I made a comment relevant to this issue in #1884 (comment) regarding the complexity of the steps to enable Prioritised Background Activity, using the Android system UI.

In the following, PBA indicates enabled Prioritised Background Activity and "!" is a .not. operator:

CWA passes me to the Android system UI heading "Optimise battery usage" (= !PBA)
where I see the "Apps not optimised" filter (= !!PBA = PBA)
where I select "All" filter (finds PBA and !PBA) which I need to use because there is no filter for "Apps optimised"
then I seek the Corona-Warn element which has a slider (!PBA), so to ENABLE Prioritised Background Activity I DISABLE the Corona-Warn slider.

This is all logical, but complex and confusing. I need to think hard any time I need to do it.

@MikeMcC399
Copy link
Contributor

@timokau

If I remember correctly, the syncthing-android app was able to directly prompt me to disable battery optimization for that app. I just had to approve it, and it was done. Similar to a normal permission prompt. Corona-Warn should do it the same way.

Until and including version CWA Android 1.5.1 selecting ALLOW for Prioritized Background Activity directly disabled battery optimisation for the app. Because this didn't work well for all devices, there was an FAQ article https://www.coronawarn.app/en/faq/#battery_optimization_background written to warn that it may be necessary to restart the device in order for the battery optimisation setting to become effective. I just checked this on an Android 11 emulator with version 1.5.1 and I had to carry out a cold boot on the device to get the setting to be applied, so that confirms the information in the FAQ.

Starting with CWA Android 1.6.0 selecting ALLOW for Prioritized Background Activity in CWA does not apply the OS battery optimisation setting for CWA directly, instead it puts the user into the Android Settings UI to allow the user to carry out the action themselves. The CWA UI instructions really don't tell the user what to do. That could perhaps be improved, or we could consider having this described in more detail in an FAQ article.

@timokau
Copy link
Author

timokau commented Dec 19, 2020

I think it would be preferable to have a simple "allow" prompt, even if it requires a reboot on "a limited number of Android devices". If it is possible to check for such devices / vendored OSes, the app could even have some special casing for those (ask them to reboot or open the settings dialog).

I think that would be better because

  • rebooting is arguably easier than manually disabling battery optimization and
  • in most cases, it will probably either work without rebooting or the user will reboot the device in some reasonable time.

There would be some cases where the setting doesn't apply and the user will not reboot for a long while. But I'm fairly certain those will be less than the amount of users that are currently put off by the confusing settings dialog.

@tomjschwanke
Copy link
Contributor

tomjschwanke commented Dec 22, 2020

The main problem are different UIs for different manufacturers. As @MikeMcC399 said, he has sliders on his Samsung device. I on the other hand have a different UI without sliders (OnePlus, see attached screenshots).

Screenshot_20201222-210413.jpg
Screenshot_20201222-210421.jpg

@daimpi
Copy link

daimpi commented Dec 22, 2020

In this context the post by @ubuntudroid might also be relevant:

There also is a library which helps routing the user to related settings screens on many devices: judemanutd/AutoStarter

At the core it's just just a collection of setting intents.

@dsarkar
Copy link
Member

dsarkar commented Dec 28, 2020

Hi @daimpi, will forward your hint to the devs. Thanks. DS

@mtwalli
Copy link
Contributor

mtwalli commented Mar 9, 2023

No planned

@mtwalli mtwalli closed this as not planned Won't fix, can't repro, duplicate, stale Mar 9, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement Improvement of an existing feature mirrored-to-jira This item is also tracked internally in JIRA UX Issue related to UX aspects
Projects
None yet
Development

No branches or pull requests

8 participants