Started using a separate thread which calls startActivityAndWait
for starting apps. Also increased the minimum and maximum lengths
of time to wait for apps to stabilize.
Change-Id: I49935a0ed1d1c230e58dc1629e5e4da6b3887903
The input method manager service now keeps track of whether or not
the ime was shown on the keyguard. This prevents activities behind
the keyguard from incorrectly showing the down-caret in the keyguard.
Bug:7498792
Change-Id: I0de01ec29cb544e902305b0f9d9fb94a73835e7b
The logic here was backwards, causing the (softer) fallback vibe
pattern to be applied if the notification specified a sound
(or DEFAULT_SOUND) and also DEFAULT_VIBRATE. The fallback
vibe should only play if you have *no* vibration set.
Bug: 7588655
Change-Id: Iecdd362729bccedf779b51cc9b90a12014328aff
* commit '0ee790408e19a2a820a080a8b4ad3af63d3a5eca':
Revert "NumberPicker should adjust min and max when displayed values are set." (a.k.a. Santa is back)
* commit '1586168302f79d10e85a5aeed7b486c4244cc98e':
Revert "NumberPicker should adjust min and max when displayed values are set." (a.k.a. Santa is back)
* commit 'e9812bae0e0ce08bd232dc2371fdb959e4f7a318':
Revert "NumberPicker should adjust min and max when displayed values are set." (a.k.a. Santa is back)
This reverted change was adjusting the min and max values for the NumberPicker
which is not desirable since it changes behavior and it will be possible for
an app that works on the current platform to crash on an older one. Also the
adjustment was not implemented correctly.
Updated the documentation to clarify the reltionship between the min value,
max value, and the displayed values array.
Bug:7518172
This reverts commit a1410e6789ce72bc423793315a51aea8b6bad6c7
Change-Id: I109f1b1f54c1e609941243cabab9241871b6b12b
- When notifications vibrate as a fallback (that is,
because they want to play a sound but the device is in
vibrate mode), this no longer requires the VIBRATE
permission.
- As a bonus, if your notifications use DEFAULT_VIBRATE,
you don't need the VIBRATE permission either.
- If you specify a custom vibration pattern, you'll still
need the VIBRATE permission for that.
- Notifications vibrating in fallback mode use same
vibration pattern but can be changed easily in future.
- The DEFAULT_VIBRATE and fallback vibrate patterns are now
specified in config.xml.
Bug: 7531442
Change-Id: I7a2d8413d1becc53b9d31f0d1abbc2acc3f650c6
This reverted change was adjusting the min and max values for the NumberPicker
which is not desirable since it changes behavior and it will be possible for
an app that works on the current platform to crash on an older one. Also the
adjustment was not implemented correctly.
Updated the documentation to clarify the reltionship between the min value,
max value, and the displayed values array.
Bug:7518172
This reverts commit a1410e6789ce72bc423793315a51aea8b6bad6c7
Change-Id: I109f1b1f54c1e609941243cabab9241871b6b12b
- When notifications vibrate as a fallback (that is,
because they want to play a sound but the device is in
vibrate mode), this no longer requires the VIBRATE
permission.
- As a bonus, if your notifications use DEFAULT_VIBRATE,
you don't need the VIBRATE permission either.
- If you specify a custom vibration pattern, you'll still
need the VIBRATE permission for that.
- Notifications vibrating in fallback mode use same
vibration pattern but can be changed easily in future.
- The DEFAULT_VIBRATE and fallback vibrate patterns are now
specified in config.xml.
Bug: 7531442
Change-Id: I7a2d8413d1becc53b9d31f0d1abbc2acc3f650c6
Prior to this fix, one user could log into another user's account by
waiting for FUL to recognize them on their account, and then
switching to another account at a very precise time - after FUL has
recognized the user but before the device has unlocked.
This was caused by the FUL unlock() callback telling the device to
unlock even though the user had changed. The fix is to only unlock
the device if the current user ID matches the user ID used to run
FUL.
Change-Id: I516b52d99ab7609b836939e4aae6e7df77a9e047
The new approach is to create two views:
- Widget preview, drawn at full-size, then scaled to fit frame.
- Fullscreen preview, drawn at full-size, used during animation.
Two views are necessary to both ensure the widget scrolls properly
with the widget page yet still appears to scale up and match
the camera app pixel for pixel.
The offscreen bitmap and associated background rendering is no
longer necessary. This avoids the large allocation and associated
rendering time after turning screen on.
Also fixes 1px horizontal discrepancy during old scale-up anim.
Also suppresses long-click behavior on the camera widget.
Bug:7471107
Bug:7559755
Change-Id: I1d834aa743bc05d6a7e2ce3eadfee8d5ff40da37
The new test is more general, allowing mobile RSSI to be
shown on devices without voice telephony.
Bug: 7490266
Change-Id: Ib5b243c0d92e74fe4385989c3a6c16edd00a9ec9
