Merge commit '453dd50e707aa3a4d24240935f3ff7ea0a08dc7a'
* commit '453dd50e707aa3a4d24240935f3ff7ea0a08dc7a':
Fixes a compatibility issue with users that have the old TTS
Merge commit 'da93c26a3d2ee0b7d51561b786bde63b7b238c50'
* commit 'da93c26a3d2ee0b7d51561b786bde63b7b238c50':
Propagating the error codes through the TtsService
Merge commit '21509240b0ba00675ffc69038f20726bf8666c57'
* commit '21509240b0ba00675ffc69038f20726bf8666c57':
Fix a bug where clicking the "more results" suggestion with the trackball
* changes:
Fix a bug where clicking the "more results" suggestion with the trackball did not seem to expand to show the corpus selectors. (http://b/1906643)
Merge commit 'd2882fa1790a976d939f29a5e39e5e7d1bc677f2'
* commit 'd2882fa1790a976d939f29a5e39e5e7d1bc677f2':
Fixes#1963214. ProgressDialog was using the wrong indeterminate progress asset.
did not seem to expand to show the corpus selectors. (http://b/1906643)
It turns out that when the trackball was used to select this item, onItemClick
was getting called on the listener twice in AutoCompleteTextView#onKeyUp:
once when we call onKeyUp on the DropDownListView, and once a little further
down when we call performCompletion(). In our case, performCompletion() is
useless since it was intended for normal AutoCompleteTextViews which populate
text into the TextView when an item in the list is clicked, but we do not
rely on this. So the easiest fix is just to make performCompletion() do nothing
in our SearchAutoComplete subclass.
Merge commit '991eec03a73f8803d0f8c80b418480ea25293cfb'
* commit '991eec03a73f8803d0f8c80b418480ea25293cfb':
Don't re-parse the framework resources all the time.
Merge commit '79ec07b333f8982ee83de8eeb0b1927a6cb112ed'
* commit '79ec07b333f8982ee83de8eeb0b1927a6cb112ed':
Fixes#1444844. Set a maximum fling velocity in scrollable views.
Merge commit '56fbd8d86a1ea60ae42185349cf8809df24d262a'
* commit '56fbd8d86a1ea60ae42185349cf8809df24d262a':
Fix the comment -- "charged" not "sharted." Also, the other
* changes:
Fix the comment -- "charged" not "sharted." Also, the other strings on that screen seem to have periods. I think that's wrong, but it's better to be consistent that right.
Merge commit '57f2cba2db4b5565b0f70bd5501e8d964dce3ad4'
* commit '57f2cba2db4b5565b0f70bd5501e8d964dce3ad4':
Fix the comments for the string resources for the charge status.
Merge commit '0d725f7d5a7efd9dc63f6ddb67a619d659bb4428'
* commit '0d725f7d5a7efd9dc63f6ddb67a619d659bb4428':
Hold a wakelock during backup/restore/clear operations
* changes:
Fix bugs 1317754 - "Idle screen displays "Charging (100%)" even when fully charged." and 1885870 - "Shorten 'Clear notification' button to 'Clear' to match latest design"
Merge commit 'ef1f21b34f5624adb7436d3da927660ed16c97c7'
* commit 'ef1f21b34f5624adb7436d3da927660ed16c97c7':
Don't trim() in the mediascanner, as that would remove the special "sort first" character.
Merge commit '816cf52abd8f45770f0ac922bbb819184ed4b90f'
* commit '816cf52abd8f45770f0ac922bbb819184ed4b90f':
Fix the DEFAULT_SORT_ORDER value for media files. Changing this
We need to make sure we stay alive for the duration of a backup or (especially)
restore operation. The existing Handler-based timing system was simply not
properly functional, so it's been retooled to use a repeating alarm delivering a
broastcast PendingIntent to our registered receiver.
We acquire a partial wake lock in the broadcast receiver [i.e. while the Alarm
Manager is holding one for the duration of broadcast delivery] and pass the
wakelock object to the backup thread, which eventually releases it when it's
finsihed operations. A similar pattern is used for the threads handling restore
and clear.
