Try harder to test for liveness. There are situations where
the lock might not be held but the input system is stuck in
a callback into the window manager policy that has hung.
Bug: 5094994
Change-Id: Iff88655512a5dc8bbb4615be65f4115e975c020b
Added new API to enable cancelation of SQLite and content provider
queries by means of a CancelationSignal object. The application
creates a CancelationSignal object and passes it as an argument
to the query. The cancelation signal can then be used to cancel
the query while it is executing.
If the cancelation signal is raised before the query is executed,
then it is immediately terminated.
Change-Id: If2c76e9a7e56ea5e98768b6d4f225f0a1ca61c61
Export trace information via abstract Unix Domain Socket (UDS).
This allows tracing of applications without INTERNET permission,
and should be faster as well.
Change-Id: Iabb67fcc2bc2484afd8128af07dca723b81c52c6
This attempts to fix an issue where sometimes the time shown on lock
screen was really old. The code now sets the time immediately when the
screen turns on.
Change-Id: Ic4649ea342499aea82f997ba488bc2cb45987739
- also clean some destructors (was not quite compulsory because
they are related to some Singletons)
Change-Id: I3091cac7b38628cda593d72570ba7a5d7ea2a15c
Up to now, audio focus was implicitly requested and abandoned
when changing the audio mode. This is no longer the case so the
behavior with regards to audio focus can be indepently set by
the CallManager.
The logic implemented here is the same as the one previously used
in AudioService:
- only request audio focus when the ring volume index is > 0
when ringing,
- request focus before setting the audio mode to a mode other
than normal
- abandon audio focus after setting the audio mode to normal
Change-Id: Ia543dc779563dbff09414771fee60e589dfaab9d
Don't automatically change the audio focus when
the audio mode changes. This is best handled by the
applications that change the audio mode so they
can address their usecases as they please (for
instance to define the behavior when switching calls).
Replaced the implicit "mode to focus" behavior with
two methods to request and abandon audio focus. These
methods are only to be used by the framework, and maintain
the logic in AudioService to prevent other apps to request
audio focus during a call.
A susequent change will update com.android.internal.telephony.CallManager
to take advantage of these two methods.
Change-Id: If84ebd508e985083e8cac82ece44940c72b5c669
The new mapping are
Four bars: RSRP >= -95dBm
Three bars: -105 dBm <= RSRP < -95 dBm
Two bars: -115 dBm <= RSRP < -105 dBm
One bars: RSRP < -115 dBm
No bars: No Service
bug:5640958
Change-Id: I9efabaeac33b624ea0a58a4d3760169dff6544f6
BUG=5614887
This fixes a timing issue where we could calculate a delay of 0 (indicating
wait forever) when we have no pending commands to actually execute. In such
cases, we should just break out of the playback loop.
This also fixes a small issue with returning whether or not to redraw.
Change-Id: Id1e481679341773256b7287062c68925e2bc8f9e
Was a mix of audio_source_t, uint8_t, and int.
Related fixes:
- fix comments in MediaRecorder.java
- AudioPolicyService server side was not checking source parameter at
all, so if the client wrapper was bypassed, invalid values could be
passed into audio HAL
- JNI android_media_AudioRecord_setup was checking source for positive
values, but not negative values. This test is redundant, since already
checked at Java and now checked by AudioPolicyService also, but might
as well make it correct.
Change-Id: Ie5e25d646dcd59a86d7985aa46cfcb4a1ba64a4a
