GitLab

Bug: 27531029
Change-Id: I1abfb08f8bcef310d25840101e92a237eccccceb

Bug: 27350753

The build system will inject the correct targetSdkVersion.

Change-Id: I4473336d02d1421c19c425899af1fd7b8b2af767
(cherry picked from commit c45787fae0a3e016c2b1cc87042266d323a9a3f6)

* goog/ub-deskclock-dazzle_nyc: (122 commits)
  Add android.support.design proguard flags
  Use ACTION_LOCKED_BOOT_COMPLETED on API 24+ - DO NOT MERGE
  Teach DeskClock about file-based encryption. - DO NOT MERGE
  Refactoring SharedPreferences to common location. - DO NOT MERGE
  Use AppCompat's imageButtonStyle attribute - DO NOT MERGE
  Use SimpleItemAnimator - DO NOT MERGE
  Bump version to 4.5.0 - DO NOT MERGE
  Do not assume current stopwatch lap has positive duration
  Avoid IndexOutOfBounds when deleting timer - DO NOT MERGE
  Fix snooze event tracking
  Rebuild notifications after app upgrade
  Fire timers as scheduled after app upgrade
  Create AlarmObserverPreL in onCreate
  Handle deleted timers gracefully
  Fix alarm not firing in memory-pressure situations
  Promote TimerService to the foreground while expired timers exist
  Match firing alarms for SEARCH_MODE == alarm.next
  Fix alarm icon cut off in 1x4 digital widget on nexus 5
  Import translations. DO NOT MERGE
  Attempt to avoid early death of AlarmService
  ...

Change-Id: I422291e92ca76a901aba0d192749789916495711

Change-Id: Ib56c2edf4f37eaf90b442e0e2c4342046fe839c1
(cherry picked from commit 581aa2ea)

am: f8e562f6

* commit 'f8e562f6':
  Do not assume current stopwatch lap has positive duration

Bug: 25860525
Change-Id: I96a502fe08ffc6ac77be25f62f6ae019c7f88280

Bug: 25860525

When running on a device that supports FBE, all persisted data is
stored in the device-encrypted area.  Also mark core components as
being encryption-aware so we can schedule and trigger alarms while
the user is still locked.

Change-Id: I7517be716468b09eed0c007600abd1937e203449
(cherry picked from commit 4a025d30)

Bug: 25860525
Change-Id: I20a012be5aadcd743a03481a72fea7f3d4750fdd
(cherry picked from commit 942b3a39)

Bug: 25896454
Change-Id: I17b82001b1e0da7b7c642f95e96e406d58a77e00
(cherry picked from commit aacfcd67)

Bug: 27203822
Change-Id: I64739aef740620c9a894f599622f679ec4fdf977

Bug: 27203822

- Set targetSdkVersion to 24.

Change-Id: I72e3452c69b151a09d4f83d222b59ed862a0d537

Bug: 27171498

After a device reboot the realtime clock is reset. Because of this, the
app is notified of the BOOT_COMPLETE and resets the stopwatch.
There exists about a 10 second window of opportunity before the
BOOT_COMPLETE broadcast in which the app may be opened and
the realtime clock information may be used to compute stopwatch
laptimes which would be negative. This case is now handled gracefully
rather than crashing on a sanity check.

Change-Id: I0eb4da0a9a55b5abc8d6abaa5a2e046821d39a2e

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

Bug: 26902786

This fix was already made downstream; no need to merge.

Change-Id: I9cf0d983963b2ab5b900b10b28ef8e013b56081a

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

am: 939d743b  -s ours

* commit '939d743b':
  Import translations. DO NOT MERGE

am: 79e47da7  -s ours

* commit '79e47da7':
  Import translations. DO NOT MERGE

am: f5a23796  -s ours

* commit 'f5a23796':
  Import translations. DO NOT MERGE

am: 6a3fb8e1  -s ours

* commit '6a3fb8e1':
  Import translations. DO NOT MERGE

am: 23c8952d  -s ours

* commit '23c8952d':
  Import translations. DO NOT MERGE

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

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

When running on a device that supports FBE, all persisted data is
stored in the device-encrypted area.  Also mark core components as
being encryption-aware so we can schedule and trigger alarms while
the user is still locked.

Bug: 25860525
Change-Id: I7517be716468b09eed0c007600abd1937e203449

Bug: 25860525
Change-Id: Ia015e1d9f5318aa366a35a2699da12d1669e7df5

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

Change-Id: Ibc77f169c16e4bff109c8d213e607a500765b228

Bug: 26676584
Change-Id: If6e905328265ad626ad9cc19b0ff6f128bdfe3a4

Bug: 26676588

Timer refactoring has removed TimerReceiver, however, timers
scheduled in 4.2.1 and prior use TimerReceiver as the entry point
for expiring a timer. TimerReceiver must be kept in place for at
least one release cycle in order to correctly fire legacy timers at
their scheduled time.

Change-Id: I0e3a751fce981fc22911d869f375b0cd40dde438

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

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

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

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

Bug: 26190910
Change-Id: Ie0c844708d51b04be504c8dd68e358e017f2e28f

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