GitLab

Bug: 26484535
Change-Id: I32e8f1c5f8620109affc25e3bb4a826856759eec

Bug: 26591272

Prior to dazzle, timers could inhabit a state of "DELETED" (value = 5).
In dazzle and beyond there is no reason to preserve such a state, but
it is possible for timers to exist in SharedPreferences in such a state,
so it must be handled gracefully.

Change-Id: I1754ef898dfff84c0a3e807c4bd0dd1473f87aad

Bug: 25846551

The original form of the code that fires an alarm is:
AlarmManager -> BroadcastReceiver -> Service.

The new form of the code that fires an alarm is:
AlarmManager -> Service.

Evidence exists that the system lowmemorykiller may elect to kill the
clock app after BroadcastReceiver.onReceive(...) completes but before
Service.onStartCommand(...) begins. When this occurs, the results are
disastrous as the clock fails to fire at the appropriate time.

To remove this possibility, all alarm state changes are delivered to the
Service. The methods that manipulate database state within
BroadcastReceiver have been made public and static and are called
directly from the Service to perform the same work as before. If the
alarm state transition is to the FIRING state, the AlarmService also
performs the work of posting the firing notification in the foreground.
All of this occurs during the handling of a single Intent on the same
thread within the service which should no longer provide
lowmemorykiller with any opportunities to prevent the firing of an alarm
by killing the clock app.

Change-Id: I3629a5b725a758f680f41611939a5bbeec23238a

Bug: 26471891

This makes the clock app unlikely to be killed in memory pressure
situations while expired timers are ringing.

Change-Id: I89f141a835e3de67a58671d6c5b381de52be5c18

Bug: 25084547
Change-Id: I62df341b463d976264bf5fa84dbc5c22b6d1cd4c

Bug: 26190910
Change-Id: Ie0c844708d51b04be504c8dd68e358e017f2e28f

Change-Id: I9857577797267755f5b634732d76e597f643042b
Auto-generated-cl: translation import

Bug: 26058053

Evidence shows that AlarmService is being destroyed a couple 100
milliseconds after starting. This can be catastrophic as it typically
means that the ringtone playback is ended before it even sounds.

This CL balances the binding/unbinding calls in AlarmActivity to
AlarmService to encourage the UI to stay in the foreground and
keep the service alive and the ringtone playing.

This CL also removes unnecessary cancel()ations of notifications.

Change-Id: I59b35dc8404dbd1f8d74285aa34a7cd81ec5545b

Change-Id: I99b0010be7f1b3fd8bae24147e80acbdd5f0c71f
Auto-generated-cl: translation import

Bug: 22371346

This is a use case that can only occur via system intents and not
via the user interface. Since the utility of pausing and/or resuming
an expired timer is dubious at best, the effect is now changed to
reset the expired timer.

Change-Id: I28c7500d1393dcfade1303b31de750c525dd0df3

Change-Id: I142ba61896ebddb20aa7dd76c1c555fb89fee99f
Auto-generated-cl: translation import

Bug: 25895834

ag/811037 left a bug in place that this change addresses.

Specifically, if a one-time alarm is missed, an entry is left in
the alarm_instances table with a state of MISSED. The query's
join clause would not return a row for the alarm in this case.

A subselect is now used to return the alarm_instances row with
the smallest state value. This means:

 - SILENT instances are preferred over MISSED instances
 (the only case where 2 instances exist for the same alarm).
 - MISSED instances are returned if they are the only instance for
 an alarm (the above case)

Change-Id: I31de6d8b2d2bf7719f6b027a2401b1da1a09f247

Bug: 24341005
Change-Id: I558c6d15316c9391ae57b96b7324ebdf1eddc29e
(cherry picked from commit 09e29779)

Bug: 25695607
Change-Id: I41c20a905566f36827b433631baee97362ad7d02

Change-Id: I93002905a560686d0bbdc6535c4fe3506da45526
Auto-generated-cl: translation import

TimerIntentsTest actually caught this bug. The intent to show
the timer tab requested that a freshly deleted timer be displayed.
This can produce exceptions if it was the last timer.

When a timer is deleted, the timer tab can be shown but no
specific timer should be requested for display.

Change-Id: I7024fbe5a154d5ecb8d563c80c09044d3917ab50

Change-Id: I573d63871f3c2ad4949131c9419a32ff0f24b8b9
Auto-generated-cl: translation import

In order to sidestep b/25872174 it was agreed that code attempting
to show the "Night mode" menu item on just the clock tab would be
removed.

Change-Id: I842b093c7d206dc8e42a6a85bbd487dd9a235942

Bug: 24496589
Change-Id: Ic79b44e47824e3a1a494f28b87d2dde9a0a0d9f9

Bug: 24496589
Change-Id: I3bc06064fd13dfdefc91db04cfe678ee7e840645

Bug: 25843144

Attempting to view a specific timer trumps the timer setup screen
in all cases. onResume() now enforces that policy. The timer setup
screen is still displayed in all other cases, including:

- no timers exist
- the intent indicates a new timer should be created
- the last visible timer screen was the timer setup screen

Change-Id: I28d147cadeb29055fa0c68a44da6648f6ad33238

Change-Id: Ic357a1d328f780b68a8c9ff48d49086f830c6d9e
Auto-generated-cl: translation import

Bug: 25302368

The bug was already fixed as part of b/19651361 but I wanted to
add the reported use case to the corpus for better regression
testing.

Change-Id: I51f80cfbbae01681b018d249de56d0d39b4122d2

Bug: 25780110
Change-Id: I454ee709d296c7a2860281b2e981476608df1e57

Bug: 25779786

The issue here is that TimerSetupView actually customizes the fab.
These customizations include setting it invisible. It was a poor design
to share the fab with this view. So, the fix is that the view now holds
its own fab-like button that it is free to manipulate without fear of
altering the app-wide fab state unintentionally.

Change-Id: Ie83b03c98db4f77e0be912b122b6f74c2c7e6c8a

- add precision to some wording for translators
- update widget provider XML layout

Change-Id: I78d7d29b2ed2ea4768c0e36d125b38df971c1484

Change-Id: Ife7cf799c6d9ca5cf15deff3337526295fdf19b5
Auto-generated-cl: translation import

Bug: 24977472

By default, the menu is inflated after the first draw. A proactive
call to Toolbar.inflate(...) during creation defeats this default
behavior.

A second problem is that the menu that is inflated by default for
DeskClock contains the search menu item which is briefly shown.
By defaulting that menu item to be invisible and only making it
visible when its corresponding controller exists, the
dancing/flashing effect is avoided.

Change-Id: I933ab9a59b471abe26e1cf07385e4a4c128d1808