* Add code to persist per-admin setting
* Add hooks for OS-level tie-in (is supported, get / set status)
* Add 3rd API call to get OS status (irrespective of admin settings)
* Remove "REQUESTED" status, no longer relevant with 3rd API
* Fixed bug that impacted global proxy settings
* Update api/11.xml to match current.xml
Bug: 3346770
Change-Id: I56bdf9a7894f6ca4842402c7b82ddb3caf4b37b9
1. If the scroll is exactly divisible by the scroll item height
the selector wheell is one off from the current value/text input.
Change-Id: I12721e85a99f6a5b51f5ad6f13c3836cb156c9a4
Some StorageManager API was accidentally unhidden during a bad merge.
Re-@hide the API to fix it.
Bug: 3362407
Change-Id: I5ad6925d3b6c18c33230127b1318c150d028a010
This reverts commit 6c4d904851772313930f800ac7c323cf90c709bb.
Going with a different tactic that doesn't dump stuff on
PackageManagerService.
Bug: 3214719
Change-Id: I0bbeccf3c21d264deda4256eb53713d2c98284f4
bug:3360821
1. While my previous change:I3baff68c has partially fixed this bug
it was still possible for a callback to be invoked on init. If a
callback was already regitsered and the init is called the
callback is incorrectly notified.
Change-Id: I05c6cb78f4c7b7d2a00c52aef42c1698d9479be5
The problem is that SoundPool never calls the onLoadComplete() callback
when load() method fails because the file cannot be opened.
AudioService loadSoundEffects() was blocked waiting for a callback
that never came.
In this particular case, this happened on a specific build where sound
effects assets were not included.
The fix consists in waiting for the callback only if at least one sample is
accepted by SoundPool load().
Also moved the initial loading of sound effect samples from the boot completed
broadcast receiver to the audio service message handler to avoid waiting in the
main system server thread.
Change-Id: I902e5988f8b644a81d8e585c52eed1df4ca0ec05
ContentProviders are allowed to return null and both
of our contact directories (Focus and Exchange) actually
do when they find no data to return.
The problem is that when LoaderManager receives a result
from a loader, it checks if the result is the same as
previously received. That's fine, as long as the loader
always returns a different result. Now consider a loader
that returns null when it cannot produce the result.
What we are seeing is that if the loader is rapidly restared
and returns null twice in a row, the null is never
delivered to the callbacks.
In the case of the reported bug, the scenario is this:
1. We look for "foo"
2. Data for "foo" comes from a directory and we display it
3. We hit backspace twice in rapid succession. Each time
we hit backspace, the loader is restared, but since we do
this very fast, the second restart overrides the first. So
far so good.
4. The directories are programmed to return null if the
query string is less than 3 characters long, so the loader
returns null twice.
5. Loader manager looks at the final result, compares it
to the previous result and since they are the same (both null)
concludes that it does not need to deliver either of them.
6. The UI attempts to show the stale data and blows up
Bug: 3352125
Change-Id: I3e5bc505faa03f72ebe5cb010377a740f5c7d5b6
