easer doesn't start on boot

[craftyguy]

Using the latest version on f-droid as of this report, 0.3.5, easer doesn't start on boot despite enabling the option in settings to do so. I experienced this issue a few times after rebooting my device and meeting certain conditions that should have triggered an action in easer (e.g. connected to wifi AP --> do some action). If I manually launch easer, then suddenly the event triggers.

[renyuneyun]

That's weird, because that part of code is intacted after the settings page is added.

The second behavior is expected because currently Easer starts the service automatically when it is opened. I should have removed it, but I forgot...

Do you have any system settings (or apps) which may affect autostart?

[craftyguy]

@renyuneyun I don't have anything running that would prevent apps from starting up, as best as I can tell. I have Easer added to the list of "don't optimize for battery" apps, but I wouldn't think that would cause this issue..

I am running Android 7.1 (CopperheadOS), if that helps.

[renyuneyun]

Indeed it's strange. (and sorry for the long delay as I was busy during last few weeks.)

I haven't used any 7.1 phones so am not sure if anything changed in the system could cause that.

I'll push a minor changed version to remove the auto-starting of the service during app startup. We may then be able to identify whether the autostart on boot of the service is affected or not.

[ildar]

Clayton, do you see the "Stop" button active in the app properties? Also logcat right after start would show something, give it a try

[craftyguy]

@renyuneyun

I'll push a minor changed version to remove the auto-starting of the service during app startup. We may then be able to identify whether the autostart on boot of the service is affected or not.

I see now that when I reboot and start the app, Easer shows that the background app is not running and it has to be started. The only change here is that Easer shows it not running, whereas before it would show the background service was running (but I had to hit 'start' for events to register).

Also logcat right after start would show something, give it a try

I can give this a try later. Logcat is super chatty, are there any fields I could match on to minimize the noise?

[renyuneyun]

Then there seem to be some issues with the auto-starting (of the background service EHService).

Maybe you can filter logcat by the app id ryey.easer.

I didn't add too much of this part to the logcat (because I thought that should work correctly). The only thing can be observed (throughtout the auto-starting process) is the last step: whether EHService.onCreate() is called or not...

[craftyguy]

I'm confused by this experiment, since EHService will not start on boot now due to 98d62f4. How exactly will a logcat help now?

[perepujal]

In my phone, I had autostarts preventing easer to start on boot, after allowing that, then logcat complained about easer not having the RECEIVE-BOOTUP-COMPLETE permision.
After adding it, now easer starts on boot.
HTH
Pere

[renyuneyun]

@craftyguy Well, that change was not to let EHService start when Easer starts (currently, the UI), not the system boot.
The start-on-boot receiver is ryey.easer.core.BootupReceiver, and it will listen to the android.intent.action.BOOT_COMPLETED Intent (signal) and start EHService. That Intent should be broadcasted by the Android system automatically when it is started and all apps (that are interested in this Intent) should receive it and take their designed actions.

The current problem chain is that:

• EHService is not started; which means
• BootupReceiver is not triggered; which means
• android.intent.action.BOOT_COMPLETED is not received by Easer

Although there may be special cases that the two "which means" don't hold, they are quite unlikely to happen (e.g. BootupReceiver is triggered, but it is killed immediately somehow (e.g. because there isn't enough memory)).

Debugging through logs could find out what happened, but we need to find out why the process do not happen.
The only way (that I am aware of) is to inspect into android to see what happens after it emits android.intent.action.BOOT_COMPLETED, but this doesn't seem to be possible...

[renyuneyun]

@perepujal Wow, good to know autostarts functions by blocking permissions (I was always wondering how it works) :)

[perepujal]

Hi, I think I didn't explain correctly, I didn't see any logs when I had autostarts blocking easer.

The complaints about easer not having the RECEIVE_BOOT_COMPLETED permission where later when I already had whitelisted easer in autostarts, so, as a quick fix, I added the line
<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />
to the app/src/main/AndroidManifest.xml file, recompiled easer and reinstalled, now I have easer starting on boot.
All this in a Wiko Wax, Android 4.3, rooted, with easer moved to be a system app. Don't know if the added permission will help in plain non rooted Androids.
HTH
Pere
As a guess, autostarts seems to block somehow the BOOT_COMPLETED Intent , guess made by not seeing any complaint in logcat when I had easer blocked from autostart and seeing the complaint after whitelisting it.

[renyuneyun]

Thanks a lot @perepujal ! At least this points out that I forgot to add the permission to AndroidManifest :( Silly me...

The commit fixes this, and should also fix the problem.

Please reopen this issue if that's not true...

[renyuneyun]

Another issue in my code should cause this, too. However, no one seems reporting this and it functions on my phone (but it should not be functioning according to the code)... Strange...

That is: I forgot to register the listener so no handling of the change of the "enabled" setting is presented.
The "fix" is in commit 4e293c4 .

[craftyguy]

Actually, it still doesn't start on boot for me (0.37), I just forgot to report back here :) I'll test that commit when a new version hits fdroid.

…

On October 5, 2017 2:24:50 PM UTC, renyuneyun ***@***.***> wrote: Another issue in my code *should* cause this, too. However, no one seems reporting this and it functions on my phone (but it should not be functioning according to the code)... Strange... That is: I forgot to register the listener so no handling of the change of the "enabled" setting is presented. The "fix" is in commit 4e293c4 .