brandon.presley/Massive
brandon.presley
/
Massive
4
8
Fork 3
Code Issues 14 Pull Requests Activity

Use AlarmManager to manage the ending of timers #236

Closed
joseph wants to merge 0 commits from joseph/Massive:use_alarm_manager into master
pull from: joseph/Massive:use_alarm_manager
merge into: brandon.presley:master
Conversation 5 Commits - Files Changed - +223 -31
joseph commented 2024-03-08 22:35:04 +00:00
Contributor
Copy Link

From the discussion in #235, I have implemented AlarmManager to schedule the expiry of the timers.

This follows how the android clock deals with timers 1 2.

Unfortunately the docs on AlarmManager and setExactAndAllowWhileIdle isn't very clear and is quite misleading.

To reduce abuse, there are restrictions on how frequently these alarms will go off for a particular application. Under normal system operation, it will not dispatch these alarms more than about every minute (at which point every such pending alarm is dispatched); when in low-power idle modes this duration may be significantly longer, such as 15 minutes.

This gives the impression that it counts alarms being dispatched as any alarm you set, however having a look at the source code it seems like as long as you cancel the previous alarm or the previous alarm has executed before dispatching a new one, your quota won't be effected.

I'll link the android tests for AlarmManager here, testSimpleQuotaDeferral shows how inorder to use up your quota you have to start at least more that one alarm simultaneously. As well as some other related files 1 2 3

I also tested adding multiple new sets on the emulator (various android releases) and two phones by spamming the button about 100 times as fast as I could. Suffice to say I didn't seem to hit any quota limit even when I sent off 100 new sets in under 15 seconds.

1000 - millisElapsed % 1000 is replaced with timer.getRemainingMillis() % 1000 in postDelayed. This has no behavioral change as the result of both statements is the same.

This fixes all the issues I've been having with timers.

From the discussion in #235, I have implemented AlarmManager to schedule the expiry of the timers. This follows how the android clock deals with timers [1](https://github.com/LineageOS/android_packages_apps_DeskClock/blob/56617759ab423cc57021869a0d2f4b7346b7b1ae/src/com/android/deskclock/timer/TimerFragment.java#L521) [2](https://github.com/LineageOS/android_packages_apps_DeskClock/blob/56617759ab423cc57021869a0d2f4b7346b7b1ae/src/com/android/deskclock/data/TimerModel.java#L693). Unfortunately the docs on `AlarmManager` and `setExactAndAllowWhileIdle` isn't very clear and is quite misleading. > To reduce abuse, there are restrictions on how frequently these alarms will go off for a particular application. Under normal system operation, it will not dispatch these alarms more than about every minute (at which point every such pending alarm is dispatched); when in low-power idle modes this duration may be significantly longer, such as 15 minutes. This gives the impression that it counts alarms being dispatched as any alarm you set, however having a look at the source code it seems like as long as you cancel the previous alarm or the previous alarm has executed before dispatching a new one, your quota won't be effected. I'll link the android tests for AlarmManager [here](https://android.googlesource.com/platform/cts/+/master/tests/AlarmManager/src/android/alarmmanager/cts/AppStandbyTests.java), `testSimpleQuotaDeferral` shows how inorder to use up your quota you have to start at least more that one alarm simultaneously. As well as some other related files [1](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/apex/jobscheduler/framework/java/android/app/AlarmManager.java) [2](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/apex/jobscheduler/framework/java/android/app/IAlarmManager.aidl;l=1?q=IAlarmManager&ss=android%2Fplatform%2Fsuperproject%2Fmain) [3](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/apex/jobscheduler/service/java/com/android/server/alarm/AlarmManagerService.java;l=201;drc=cc6a187eebd95e4c44e1571a3d2584d0160b01a5) I also tested adding multiple new sets on the emulator (various android releases) and two phones by spamming the button about 100 times as fast as I could. Suffice to say I didn't seem to hit any quota limit even when I sent off 100 new sets in under 15 seconds. `1000 - millisElapsed % 1000` is replaced with `timer.getRemainingMillis() % 1000` in `postDelayed`. This has no behavioral change as the result of both statements is the same. This fixes all the issues I've been having with timers.
joseph added 1 commit 2024-03-08 22:35:04 +00:00
brandon.presley commented 2024-03-08 22:46:05 +00:00
Owner
Copy Link

Incredible stuff my brother! Love your work

Incredible stuff my brother! Love your work
brandon.presley commented 2024-03-09 00:57:28 +00:00
Owner
Copy Link

Hey boss I was trying to copy your work into Flexify https://github.com/brandonp2412/Flexify/blob/main/android/app/src/main/kotlin/com/presley/flexify/TimerService.kt but I'm getting Unresolved reference: FOREGROUND_SERVICE_TYPE_SPECIAL_USE do I need to change that projects android target version or install something?

Hey boss I was trying to copy your work into Flexify https://github.com/brandonp2412/Flexify/blob/main/android/app/src/main/kotlin/com/presley/flexify/TimerService.kt but I'm getting `Unresolved reference: FOREGROUND_SERVICE_TYPE_SPECIAL_USE` do I need to change that projects android target version or install something?
joseph commented 2024-03-09 15:09:14 +00:00
Author
Contributor
Copy Link

I was getting that too when I tried copying it into Flexify - it still complains however it builds just fine for me now.
I have submitted an mr on Flexify with the changes from this mr + some fixes for bugs I encountered when trying to run in debug mode.

I was getting that too when I tried copying it into Flexify - it still complains however it builds just fine for me now. I have submitted an [mr](https://github.com/brandonp2412/Flexify/pull/1) on Flexify with the changes from this mr + some fixes for bugs I encountered when trying to run in debug mode.
❤️ 1
joseph changed title from Use AlarmManager to manage the ending of timers to WIP: Use AlarmManager to manage the ending of timers 2024-03-10 23:56:54 +00:00
joseph commented 2024-03-10 23:58:36 +00:00
Author
Contributor
Copy Link

Marking this WIP as I would like to take some of the changes I made in the Flexify mr over here.

Marking this WIP as I would like to take some of the changes I made in the Flexify mr over here.
joseph added 1 commit 2024-03-11 17:42:52 +00:00
41b9232a1b Applied changes from Flexify mr 
Fixed Alarm Manager Request Permissions
Fixed TimerHandler Delay
joseph force-pushed use_alarm_manager from 41b9232a1b to 58b8488a27 2024-03-11 19:31:22 +00:00 Compare
joseph changed title from WIP: Use AlarmManager to manage the ending of timers to Use AlarmManager to manage the ending of timers 2024-03-11 19:34:03 +00:00
joseph commented 2024-03-11 19:43:34 +00:00
Author
Contributor
Copy Link

Brought over applicable changes from here.

Fixed Alarm Manager Request Permissions
Fixed TimerHandler Delay

This mr and Flexify one should be ready now.

Brought over applicable changes from [here](https://github.com/brandonp2412/Flexify/pull/1). ``` Fixed Alarm Manager Request Permissions Fixed TimerHandler Delay ``` This mr and Flexify one should be ready now.
brandon.presley closed this pull request 2024-03-11 23:08:24 +00:00

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
bug

Something is not working

  
duplicate

This issue or pull request already exists

  
enhancement

New feature

  
help wanted

Need some help

  
invalid

Something is wrong

  
question

More information is needed

  
wontfix

This won't be fixed

No Label
bug
duplicate
enhancement
help wanted
invalid
question
wontfix
Milestone
Clear milestone
No items
No Milestone
Assignees
Clear assignees
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: brandon.presley/Massive#236
No description provided.
Delete Branch "joseph/Massive:use_alarm_manager"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?