- the old DatePicker widget is still there for obvious layout compatibility reasons
- add a new delegate implementation for having a new UI
- use the new delegate only for the DatePickerDialog (which does not need to be
the same)
- added support for Theming and light/dark Themes
- added support for RTL
- added support for Accessibility
- verified support for Keyboard
- verified that CTS tests for DatePicker are passing (for both the legacy and the
new widgets)
Also added a new HapticFeedbackConstants.CALENDAR_DATE and its related code for
enabling day selection vibration
Change-Id: I256bd7c21edd8f3b910413ca15ce26d3a5ef7d9c
Enable checkbox in settings and wire it to NotificationManagerSerivce.
Add RankingHelper to collect ranking configs and logic.
Bug: 15080024
Change-Id: Ib1d3b0b5ca4fcfdc52c2cb6838a009b9addf1094
Use ActivityOptions.makeLaunchTaskBehindAnimation() to launch tasks
behind the current task. Includes animations for launching and
launched tasks.
Fixes bug 16157517.
Change-Id: I0a94af70b4748592e94673b958ee824cfb3d7ec0
This avoids NullPointerException crash when changing values without
first canceling a running animator.
Issue #16245303 KeyframeSet crash on null keyframe or evaluator
Change-Id: I50ce5223310fe87e3382c446e2d36d93ae38a8fe
Simplify back to being a broadcast receiver and add an extra to
indicate that a new request is desired vs. returning a pending
response from before.
Change-Id: Iafd16ed98293a2cc09006d2cce097fc3d590bbe2
Flesh out documentation and finalize first cut of API. Also surface
installLocation and splitNames through PackageInfo.
Bug: 14975160, 15348430
Change-Id: Ic27696d20ed06e508aa3526218e9cb20835af6a0
Two separate issues :
- We were not parcelling the value at all.
- We were looking for it in the wrong manifest attribute.
Note that this change has no observable effect on installs (which
is probably why it wasn't caught so far). This code path is only
used in FileInstallArgs.copyApk (where multiArch was effectively
false before this change) but the package manager extracts shared
libs *again* inside scanPackageLI where this was being done
correctly since the value there came from a "full" package
parse, and not a "lite" package parse.
Change-Id: I54c3efcf8f57e6970f8fbde8cd1f57d487b13114
This is an app-private filesystem space exactly like the one
reported by Context.getFilesDir(), with one exception: files
placed here are never backed up by the full-backup infrastructure.
If an app attempts to back up any of its contents via the normal
API it's immediately ignored with a logged warning.
The restriction is also enforced on the restore side, because
apps using support libraries might wind up creating full backup
archives containing no_backup subdirs on pre-L devices (via
adb backup, Helium, &c.). We check for this before passing the
restore data to the app, and drop it if we detect the situation
so that the app never sees the bits.
Bug 16240573
Change-Id: I11216a391f1d32117ec7ce15aafc9cd93d0337de
It seems that currently there is no un-hidden way to determine if
the device is in lock task. This fixes that.
Change-Id: Ib5082b84de8073d261777b955fddff55367e5662
Move the shared element of callee activity to animation start position,
then restore the measured size and locations to original values before
call requestLayout(), this fixes cases for RecyclerView optimized layout
which offsets siblings by delta of measure size.
Change-Id: I6e43c036e26986605ff008aba476e30ebd270fd1
