Only the system can enable the car mode and the system should
already have appropriate permissions.
But since we wanna allow all other apps to disable the car mode
again, we don't want to enforce them to specify the DISABLE_KEYGUARD
permission in their manifest.
Change-Id: I1ad244a98d65b7193ea9817bff8406cfc2bce6f3
For each location provider, call getInternalState() to see if it has any
state information to include in a bugreport. If the returned string is not
null, then print a header with the provided name followed by the returned
string.
Change-Id: I0a388d7fba14ac8cadcb80eda0a0ceb95032410b
Signed-off-by: Fred Fettinger <fred.fettinger@motorola.com>
Signed-off-by: Mike Lockwood <lockwood@android.com>
This works around a bug in the
"Q3Dimension MSM7500" driver. That driver only
supports a single active EGLContext, so we must
release and restore the EGLContext when pausing
and unpausing.
Unfortunately the test for deciding whether to
release the context was inverted. We were
releasing the context on every device besides
the MSM7500 devices, which was a performance
drain, and we were not releasing the context on
the MSM7500, which meant the underlying driver
bug was not worked around.
Now we release the EGL context when pausing only
on the devices that have the bug.
The DatePickerDialog in the Settings application is not updated correctly if you follow
the following step-by-step:
1. Enter Date option in settings application
2. Modify the values of the date, then cancel the changes
3. Once again enter the date option
and you can see that the title in the dialog has not been updated correctly. This is
due to a missing call to onDateChanged callback in the DatePicker class. Solution was
to add the notify call when updateTime has been called.
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
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.
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.
