forked from darshan-/Battery-Indicator-Pro
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathnotes
115 lines (78 loc) · 4.47 KB
/
notes
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
GitHub feature requests. Particularly #4.
crash (and then fine, but still a crash and crash pop-up notification)
on boot on P2 if a widget is present. My initial guess is that when
a widget is present, Android starts BB itself, and then we get
boot completed receiver, which trys to starts service, but it can't
becaues that's already in process. So first go at fixing is to do
something in BCR to not try to start if already starting, or to
simply wrap try/catch around startService...
Playing audio myself bugs me in several ways
Complex and error prone: What if user is on phone? Play sound anyway?
Need permission to see if on phone?
Battery drain if loop for long time?
Messy and wrong feeling.
Two things people want, that I'm trying to solve here:
* Ability to override Do Not Disturb
* Ability to have alarm keep going
Do Not Disturb is likely to be workable with Notification Channels
Might not count as alarm? Just priority high? Not sure. Maybe perfect, maybe good enough.
Maybe have option to repeat alarm every minute until alarm is dismissed.
Less potential for battery drain, simpler in some ways, maybe good enough.
Alarm audio stream:
* Remove sound (or don't include it) from notification when playing it myself
* Request/Check for read_external_media
Ideally upon attempt to set ringtone to one external one?
Or keep it simple, less fine-grained?
* Update documentation
Possibly this:
Setting in "Other Settings"
"Enable Assertive Alarms"
Setting that to true shows a pop up (something else does this, right?)
(Yeah, Enable 10% mode has a pop-up verifiation, so can base on that code)
Pop up states that Assertive mode may drain battery, because it will loop the
alarm sound until the user dismisses it. It also plays the alarm on the
alarm channel rather than the default notification channel (so on most devices
it should make a sound when all sounds but alarms are silenced). If
Assertive Alarms are enabled, any alarm can select between standard alarm
or assertive alarm, and the default is still the standard. Enabling this
also requires read access to sdcard, as many versions of Android have
alarm ringtones only accessible that way. If you revoke access to external
media, an assertive alarm may not work.
If they say yes, request read external media access
If access is granted (either due to user interacation or because already granted), turn on setting
If access is not granted, or if they cancel, leave setting off.
Other:
* Light / dark theme option, and/or choose notification background color
(See BB email from Geoffrey Santoro)
* Alarm type for inadequate charging (Probably a drop of 5+ points while status charging)
(See BB email from Paul Mitchell)
* Priority doesn't mean anything on Oreo? Need to set up different channel, or something?
- Disable priority setting on 26+?
* Notification channels may be alternate method to have alarm stream?
* Notification Wizard needs to be different on Oreo
* Update Alarms to use channels
* Any other notifications?
Alarm type:
Notification
Alarm
Notification is the old way: Played by Android, not looped, standard audio stream
Alarm is played by the service, loops* until dismissed, uses alarm stream
* Some ringtones are set to loop (mostly alarms), but not a 100% mapping. (Some
non-alarms loop forever, and maybe some alarms don't. And the looping forever
also depends on device!) So my best solution is to set MediaPlayer to looping,
so all alarms treated as "alarm" type by my app are looping. (I can't make
looping ringtones non-looping**), but I can make non-looping ones loop.
** I technically have the option to listen to onSeekComplete, so that when the internal
looping that I have no control over loops back to 0, I can then call stop.
This has the disadvantage of clipping ringtones that have a few internal loops rather
than infinite looping. (Many ringtones are 2-4 loops naturally, which sounds good,
and clipping them to one is wonky.) So I think the best is to have only the two
options (Notifiation|Alarm) without an extra (loop|no-loop) setting for alarms.
(And there are some folks saying that on some devices onSeekComplete is never called
for infinitiely looping sounds, so this isn't trustworthy.)
Possibly in the future:
Three tabs
"Logs", "Status", "Alarms"
Action Bar tabs, rather than pager view
NAVIGATION_MODE_TABS
Depricated in API 21, but should work well on API 11+ anyway.