

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.


