Another fix for Service_SnoozeAlarm being killed midway #18
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Some devices are still reporting that the snooze service is being killed midway, even after e384368. In this commit, some changes have been made in AlarmBroadcastReceiver so as to prevent spurious triggering of Service_UpdateAlarm.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Some devices are still reporting that the snooze service is being killed midway, even after e384368. The behaviour is this: the service is killed, and an alarm is set on the next day (at same time) immediately.
To be honest, this is becoming frustrating.
Anyway, we have to find the places where the service is being killed, and then another alarm is being set. The only relevant place comes out to be
Service_UpdateAlarm.Service_UpdateAlarmis supposed to be started fromAlarmBroadcastReceiverwhen the following broadcasts are made from the system:Intent.ACTION_BOOT_COMPLETEDIntent.ACTION_TIMEZONE_CHANGEDIntent.ACTION_TIME_CHANGEDA Google search revealed something very interesting: a person reported that
Intent.ACTION_TIME_CHANGEDwas being triggered many times without changing time manually. The accepted answer states that this action is broadcasted many times if the device uses network provided time.As an urgent fix, both
Intent.ACTION_TIME_CHANGEDandIntent.ACTION_TIMEZONE_CHANGEDhave been removed from the manifest entry ofAlarmBroadcastReceiver. Hope this solves the issue temporarily.