Part of a fix for bug b/2300622 (Proximity sensor always blows up the lock screen while in call)
Change-Id: I9ef888638b19540a78a34507d52ff522f505102f
Signed-off-by: Mike Lockwood <lockwood@android.com>
The image buffer used by glTexImage2d() would be uninitialized when no copybit engine
can be found.
We now always initialize images, since the abscence of copybit is not necessarily fatal.
1. PRIORITY_OFF is when user unchecks A2DP connection profile box.
2. By default, when you bond, it will be PRIORITY_ON.
3. When the profile gets connected, the priority gets set to
PRIORITY_AUTO_CONNECT. This means that we will connect
automatically to this profile.
4. When the user disconnects, we downgrade the priority to PRIORITY_ON,
which means we won't reconnect automatically.
a) We need to make a similar change to Handsfree profile.
b) We need to rework the profile management design and code which
will fix the 6 second timer that we have for A2DP reconnection.
Add AUTO_CONNECT priority for Headset profile.
Also, don't set priority to ON while disconnecting.
This logic has been pushed up to the Settings app.
Dr No: Eastham
Bug: 2133530
This doesn't really fix the problem being brought up here, but fixes a
related issue I found while investigating it -- if you tap a text view
enough to cause it to try to scroll, this will cause the touch to become
a scroll instead of a click, even if there is nothing to scroll. So
often quick taps to bring up the IME would be canceled because they
became a non-scroll.
Unfortuntately after syncing the latest build, I was having a lot of
trouble reproducing the original problem. I think I need to punt it to
MR2 at this point.
Change-Id: If1f0bf33de1b4d71c9f677cdad07639b7a3fb772
1) Do not pulse notification LED when screen is on.
2) Pulse once on new notification if Settings.System.NOTIFICATION_LIGHT_PULSE is false,
otherwise pulse persistently while screen is off.
Fixes part of bug b/2238250 (trackball should pulse occasionally to indicate new email)
Change-Id: Icc49422a4e9d14412fc159a8e2596503a85bac51
Signed-off-by: Mike Lockwood <lockwood@android.com>
There was bug in the logic that calculated the relative timeout, the start time was
reset each time an event was received, which caused the timeout to never occur if
an application was constantly redrawing.
Now we always check for a timeout when we come back from the waitEvent() and
process the "anti-freeze" if needed, regardless of whether an event was received.
The problem comes from a deadlock with AudioPolicyService mutex: When the second ringtone starts,
this mutex is locked by AudioPolicyService::startOutput() which in turn calls setParameters() to change the output device.
Audioflinger::ThreadBase::setParameters() signals the parameter change to the AudioFlinger mixer thread and waits for a condition
indicating that the parameter change has been processed.
At the same time, the mixer thread detects that the audio track corresponding to the first ring tone has been killed and calls its destructor.
This calls AudioPolicyService::releaseOutput() which tries to lock the AudioPolicyService mutex.
If this happens before the mixer thread can process the setParameters() command we are deadlocked.
The deadlock ends because setParameters() uses a timeout when waiting for the condition.
This regression was introduced by change 33736 fixing issue 2265163.
The fix consists in calling AudioPolicyService::releaseOutput() from Track::destroy() instead of from Track destructor: as detroy() is never called from the mixer thread loop (as opposed to the destructor) the deadlock described above cannot occur.
There is a delay between registering the two profiles,
and handsfree profile is a superset of the headset profile.
So some devices do an SDP and get the headset profile record
before we have registered the handsfree profile.
a) We can reject all incoming connections till all profiles are
registered, but then this would mean we connect later in some cases.
Registering profiles in this order seems fine to me.
Note: There is a also the need to fix forking sdptool to register
profiles, which would obliviate the need to wait 500 msecs between
profile registrations.
Bug: 2293792
Dr No: Eastham
This fixes another case where the screen would turn on when the keyguard is open but hidden by another activity.
Change-Id: I2b7c8a329036401709e96ded4f4c138041192a71
Signed-off-by: Mike Lockwood <lockwood@android.com>
