AutoStarter icon indicating copy to clipboard operation
AutoStarter copied to clipboard

Mistaking Battery Optimization for Autostart

Open NoHarmDan opened this issue 2 years ago • 2 comments

Hi, I'm still using the library and quite happy it's being updated, but there is one thing that I think was a completely wrong decision.

I updated from 1.0.8 to 1.1.0, hoping the new version would recognize that e.g. a OnePlus 6T does not have the Autostart settings and would return false on autoStartPermissionHelper.isAutoStartPermissionAvailable(context). To mu surprise, it still returns true but instead takes me to the Battery Optimization screen. That is a different screen. My app already deals with that separately. Most apps must be. It is great to include that option, but it should never be under the same function call, because it simply is not the same thing. And looking at your code, it seems like it's been added to other device manufacturers as well.

My suggestion? Keep it, but make it a separate functionality. This is just misleading.

Rant over, sorry if I'm sounding harsh, I really do appreciate all your work. :)

Edit: Oh and having the option to get the component name or intent action or whatever you want to call it that is resolved for the current device would also be extremely useful, for example to be able to compare it with other options that are implemented outside of the library. :)

NoHarmDan avatar Jan 25 '22 15:01 NoHarmDan

I gave up on trying to make it work with what is provided, forked and overhauled it to suit my needs. Feel free to get inspired by anything or don't, either way the changes are too great to make a pull request. https://github.com/NoHarmDan/AutoStarter

And btw, one more thing - comparing installed packages may be a little contra productive performance-wise, considering the app that uses this library might've declared a much larger amount of packages to query (or even all of them). But that shouldn't be a big issue.

NoHarmDan avatar Jan 26 '22 08:01 NoHarmDan

Hey, I took a look at your forked version, it seems like you have provided a method for getting the right intent, and removed the intent with the action for the one plus device. Did you do any other changes?

Do you mind sharing: 0. Are you sure that there aren't any other inconsistencies within the library in terms of opening/checking auto start permission settings vs. battery optimization settings vs. potentially other settings. In my case, I did notice that on Samsung phones, it opens a screen related to putting/removing the app on/from the "sleep list". I am not sure if this can be considered an inconsistency. There doesn't seem to be an autostart permission on Samsung phones as well. So, maybe the issue is bigger than just the one plus problem you mention. I am not sure what is the relation between auto start permission on xiaomi phones with "sleep list" on Samsung phones, if any. This makes me wonder how can I use the library in my project in terms of showing some message before navigating the user to some screen via this lib. It seems like I will have to use some very generic UI message given that you can have different permissions on different phones. On the other hand, I can see that you do mention something about there being other phones in the library for which you had noticed some inconsistencies, but I didn't see any changes in your source code in relation to this.

For example, in this library: https://github.com/thelittlefireman/AppKillerManager, there seem to be three different types of settings. Furthermore, it seems like this library (autostart) used the package and activity which correspond to "power saving" settings from the linked library for Samsung, and not the "autostart permission" settings, even though the linked library has support for "autostart permission" settings. It seems like this library (autostart) may cramp multiple types of settings under one name. At least, this seems to be the case for Samsung. Though, I am also wondering whether one can really make a classification of different types of settings across so many different phones.

  1. What kind of problems were you facing in your project so that you needed this library, for example, problems with push notifications or something else?
  2. Did you use any other library in your project for this purpose? Or any other logic related to this problem.

In my case, I have problems with the work manager not running consistently if the app is closed on some phones and I am questioning whether to go down this route or not (asking the user for permissions). I am using the library together with some logic for checking the android battery optimization policy and it did have some positive results on my personal phones, but I am not sure if this will be the case with other phones. And, I even added an empty foreground service with the intention that the OS won't kill my app if there's a foreground service running (which basically kills the purpose of using a work manager). Basically, I want to send some data to a server on a regular basis, but the work manager stops working on some phones if you close the app from recents and if the app doesn't have the necessary permissions.

bojanlozanovski77 avatar Jul 28 '22 13:07 bojanlozanovski77