002.00.03-09API

release: '002.00.03-09API'

002.00.02-09API

release: '002.00.02-09API'

002.00.01-09API

release: '002.00.01-09API'

002.00.00-09API

release: '002.00.00-09API'

002.00.00-09API-beta04

[Android 11+] add runtime permission check: MANAGE_EXTERNAL_STORAGE

002.00.00-09API-beta03

add runtime-only broadcast receiver to Alarms ListActivity for refresh

when the Alarms (ListActivity) is visible..

previously:
* the alarm broadcast receiver (manifest-declared)
  only processed the alarms at their scheduled times
* the list did not automatically refresh as alarms are executed
  - ex: the date/time of a repeating alarm did not update
  - ex: one-time alarms were not removed

now:
* the alarm broadcast receiver (manifest-declared)
  also sends a follow-up broadcast,
  which targets another broadcast receiver (context-registered),
  which is registered dynamically by the Alarms ListActivity,
  and only exists during its lifecycle
* if (and only if) the Alarms ListActivity is started,
  this follow-up broadcast is received and triggers a UI refresh

status:
* working

conclusions:
* ".receiver.AlarmReceiver" and ".ui.Alarms"
  both run in the same process
* a common "LocalBroadcastManager" can be used by both
  to pass messages intra-process

previous commits:
* 1x commit ago:
  - 38f5bf8de91fcd7fc3a94b27b51f3d2fb58c0920
  is a fully functional implementation that:
  - uses system broadcasts
  - uses a custom permission to protect messages
* 4x commits ago:
  - 92324b9baff347d329e197c7ff6483ce440fe83c
  is nearly identical to this new commit
  - the new commit can (mostly) be considered a rollback
  - the old commit had one issue:
    * the broadcast receiver (context-registered)
      used resume/pause lifecycle events to enable/disable
    * when an alarm starts a new Activity,
      the appearance of its Activity chooser dialog
      caused the Alarms ListActivity to pause,
      which caused the broadcast receiver
      to miss the corresponding message
  - the new commit uses start/stop lifecycle events..
    problem solved

002.00.00-01API-beta02

fix: "TimeDurationPickerDialog"

needed to widen some variables from int to long,
to accomodate the larger millisecond duration values

002.00.00-01API-beta01

fix: broadcast receiver

status:
* all of the important plumbing is done
* scheduled alarms do correctly execute
* UI needs more polish
  - currently, uses a new library for a time duration dialog..
    to pick the desired interval of an alarm that repeats
    * I don't like it
    * will replace with something else
* string resource translations need updating

001.04.04-01API

[001.04.04-01API] fix: "ShortcutManager.requestPinShortcut" is API 26+

001.04.03-01API

[001.04.03-01API] update Spinners with additional common values