GitLab

Change-Id: I9cc9027ea82a90af5f369976823f0feb0a1eeda0

Change-Id: I079bdf4edfb9083eba3e15d8e4dbf3b2bad9190c

ListView#getCheckedItemIds() now works more reliably.

Bug #2258525

Change-Id: Ia347590a374f7e0b8928b0673dc10d55fe785e73

Change-Id: I0b21316ff890d7f3c7d4b82837bb60670724c2e8

bug: 2200728

This makes properties easier to read so from:
   ro.cdma.data_retry_config=default_randomization=2000,0,0,120000,180000

to this:
   ro.cdma.data_retry_config="default_randomization=2000,0,0,120000,180000"

Change-Id: Ied2a7be0102512cd2ce528d566c19ed3a8e2f480

Merge "Adding over scroll to webview. We will always apply over scroll vertically. In horizontal direction, if the page can't be zoomed and the current content just fit, we will not do over scroll."

BUG: 2477103
Signed-off-by: Mike Lockwood <lockwood@android.com>

This permits implementing interfaces which are faster than using
remote Cursors.  It then uses it for Settings & SettingProvider, which
together account for ~50% of total ContentProvider event loop stalls
across Froyo dogfooders.

For fetching Settings this looks like it should reduce average
Settings lookup from 10 ms to 0.4 ms on Sholes, once the
SettingsProvider serves most gets from in-memory cache.  Currently it
brings the Sholes average down from 10ms to 2.5 ms while still using
SQLite queries on each get.

BUG: 2367912
Signed-off-by: Mike Lockwood <lockwood@android.com>

Merge "Change an aapt "warning" from "*** " to "**** " (from three to four stars). "*** " (three stars and a space) is the 'magic make error string'; so this change makes it easier to find the real issues/errors in build logs.  Besides, other aapt messages are "**** "."

The problem is that AudioRecord never exits read() when a timeout occurs while trying
to get new PCM data from audio hardware input buffer: it just keeps waiting and retrying until stop() is called.
In the same time, opencore AndroidAudioInput::audin_thread_func() loop cannot be exited when stuck
in AudioRecord::read() because the iExitAudioThread flag can only be sampled when AudioRecord::read()
returns. We remain stuck with the audio input thread running.

The fix consists in modifying AudioRecord behavior in case of timeout when getting new PCM samples.
We now wait only one timeout period and try to restart audio record, in case the problem is due to a media_server
process crash. If this fails, we exit read() with a number of bytes read equals to 0 so that
AndroidAudioInput::audin_thread_func() loop can exit.

Also modified Audioflinger::RecordThread() loop so that we attempt to recover from HAL read errors.
In case of read error, the input stream is forced to standby so that next read attempt does a
reconfiguration and restart of the audio input device.

over scroll vertically. In horizontal direction, if
the page can't be zoomed and the current content just
fit, we will not do over scroll.

Per UI request, only draw the shadow when title bar
is not visible.

"*** " (three stars and a space) is the 'magic make error string'; so this change makes it
easier to find the real issues/errors in build logs.  Besides, other aapt messages are "**** ".

If an overlay has a type of resources that's not defined in
the main res pool, then aapt would crash.

This dynamically create new ResourceTypeSet when needed
when processing the overlays

Change-Id: I67bc3622281bde73cf42f37a0983798d3f658ce2

Merge "Instead of allocating the decoder instances in response to a call to setDataSource, postpone allocation to the preparation phase where it belongs."

Extract all UI behavior from dock observer and ACTION_DOCK_EVENT.

Also introduce a desk type to go along with the car type all through
the resource system, since we now need to have corresponding high-level
broadcasts for desk dock mode.  As part of that I also reworked some
of the logic for switching modes to all funnel through a single
update() call that looks all of the current state to decide what to
do next, and fixed various locking issues.

In addition I found there were bugs in the configuration change
handling causing us to only switch into the car mode config and
then never get out of it.  Unfortunately now that we are actually
changing the configuration for each mode change, the transitions
between them are really crummy as we restart all kinds of
activities. :(

Instead of allocating the decoder instances in response to a call to setDataSource, postpone allocation to the preparation phase where it belongs.

related-to-bug: 2492205