Some apps can get into a case where the saved view hierarchy states
for action bar views are missing. Log a warning instead of crashing.
Bug 6510800
Change-Id: I95ede64ec584892e6e76ca9ab9d53e9d3689984f
The aspect ratio sent from the camera app to the SurfaceTextureTarget
filter does not really matter now since the camera app handles
the re-sizing. Hence, the SurfaceTextureTarget filter needs to be render
in "stretch" mode all the time even though the aspect ratio sent to the
filter might indicate otherwise. The filter still needs the correct
frame size for things other than determining aspect ratio.
Fix b/6430124
Change-Id: Ie7fa5cd2adf2a8d41e6e005418f6c6fd738ed85d
...logic for notouch in Configuration
Added new TELEVISION feature.
We now force the configuration to "television" if the TELEVISION
feature is set, and "notouch" if the TOUCHSCREEN feature is not set.
Also cleaned up documentation, deprecated some configurations that
are not used.
Change-Id: If1c7a284b580a8a66bda2a75f0c7fa841b3dc9b7
This change ensures that applications producing surface texture updates
at a steady rate will display the updates on screen at the same rate,
v-synced.
Change-Id: I663685b34d12809fbf8945c44851e30a2052ce74
20 ms worked well for GN hspa for stress test, but failed sometimes
for other platform. Increased it to 50ms. Tested on all the device types
bug 6438556
Change-Id: Ic5fcde3de7ea6d3d983edab7ae3df5684637bd20
The premium SMS short code detector loads patterns from an XML resource
by default (frameworks/base/core/res/res/xml/sms_short_codes.xml).
Add support for updated patterns to be loaded on a per-country basis
from a secure setting named "sms_short_codes_" + the country code.
Updated patterns can be pushed to Google devices via Gservices.
Bug: 5513975
Change-Id: Ibfc0be4f12227ba45c28396ec7cdbc307442af81
Move MountService up the list, then pause waiting for MountService to
finish scanning ASECs before the services that require those packages to
be ready.
Additionally, don't automatically mark all ASEC apps as FLAG_EXTERNAL on
reboot. This prevents AppWidgets and other things from being used with
ASECs which are on internal storage.
Bug: 6445613
Change-Id: I3e0b3e244fec966814d7a5ea93de5d337aea79bd
Previously, the setup app was responsible for telling the backup
manager through a side band that the user had passed through the
backup/restore-related portion of the setup flow. Now that the
flow has been streamlined and certain mandatory portions of it
are no longer relevant, we can ditch the whole idea of the backup
manager's internal "provisioned" state. This makes setup and the
setup "wizard" applications less fragile as well as eliminating
the possibility of unrecoverable "backup was never provisioned"
failure modes.
Now, the only check the backup manager has to do is against the
full "device is provisioned" flag, just like all of the other
components on the phone that only become usable after the setup
process has exited [such as phone calls].
Bug 6493520
Change-Id: I13ec8dd8baa1e74ed8569b0326219a98a7f632a9
New action and extra for android.speech.RecognizerIntent:
ACTION_VOICE_SEARCH_HANDS_FREE
EXTRA_SECURE
Change-Id: I1f390ede4f4087bae1781347bb211dc0a093e857
There is a long history in Android, on both GED and non GED devices
of GPS providers ignoring the minTime parameter making location updates
every second. The problem is usually poor GPS drivers that claim to
do scheduling but then do not.
By making the minTime parameter strict (instead of a hint) we can add
a CTS test to ensure that udpates to not occur too frequently. I believe
this is the desired behavior from apps. If apps want to take advantage
of more frequent updates when another application asks for those updates
then it can use the passive provider.
The CTS test for GPS has already been submitted (as part of CTS Verifier).
Bug: 6424983
Change-Id: I163b9e44ea7ab71530b86fc2282614e0150e90f1
When somebody makes a quick setWifiEnabled calls in back to back succession,
we were missing setting the last state because we were only doing that
when wifi was in a particular state from a state machine's perspective.
This was done to handle the interaction b/w airplane and wifi and was
done in the wrong way. That part is now moved to the code which detects
airplane mode changes.
In the longer term, I want to move the whole persisting code as part of
wifi state machine which is more aware of the exact states wifi is in.
Bug: 6504534
Change-Id: I452f3f4efdeb84458dcfd280269e09ffa3844f05
Handle canceled key events correctly and don't synthesize
key events in that case.
Unfortunately, the state machine was confused by some sequences
of key events that it might receive from the input dispatcher
when new activities take focus during a long-press on the headset key.
The audio service may receive a cancel event intended for the old
window, followed by a repeated down and finally an up for the new window.
Simplified this down to just two booleans.
Bug: 6484717
Change-Id: I9587d0a5e282419ef4d7c17665940682aacea96a
Bug: 6490959
Fixes the issue where we will show the old tap highlight
if webkit isn't quick enough to respond
Change-Id: Icd9864d276b6ad311e3f3dc4deaa7085e3769006
