make sure to clear our EGL implementation's error when returning
an error from an underlying implementation
Change-Id: Ibce4726cef1f900e4c7f16002345d7a07f8cdf41
Avoids allocating new idle handler arrays on each iteration since
we only need one to copy into.
Coalesced the synchronized blocks.
Hoisted the call to Binder.flushPendingCommands() outside of the
synchronized block.
Change-Id: Iabb6b633627954564bdd5d09e696663223407f47
Also fix a Valgrind complaint by zeroing out the entire epoll event
struct since otherwise the data field union would be partly
uninitialized (but not in a harmful way).
Change-Id: I2091ce517e87fcad7c9caf90e2c5e4854a7ca465
I've noticed over the past couple weeks that my phone was flipping to
landscape when I placed it down too often, more like it did in Eclair.
I think my previous changes to make orientation changes quicker were a
bit too aggressive, so I'm backing off a couple of the time constants.
Change-Id: Ifffd45ac934984cc9091da56958bc2b6bcaa280a
Scale audio signal during capture according to peak level so that
returned values on 8 bits contain enough information even for weak
signals.
Also do not reject requests to enable/disable the visualizer if we are
already in the requested state.
Change-Id: I07a705619764350834e61f82d161761eab688747
Change-Id: I7864dd4d3e15a9dc11429d5d3268f9b078f3eaad
Constants updated to match user testing.
Recede no longer flashes out but degrades all the way to zero.
Growth of the absorb flash is now quadratic as this better
matches the "physics" of the user flicking the list.
Size of the pull and absorb graphics changed to give the user
a more dramatic indication of what has happened.
When an entity (NLP for example) acquires
a WifiLock and initiates a scan, scan can
get blocked until driver starts.
scan returns no useful info, scan results
are broadcast when obtained.
Bug: 2964633
Change-Id: Iaefc32bb6b82f0718285a18ac600e6bbbb096e77
This code uses a try/finally to maintain the old behavior of setting
implCreated even if creation fails.
Change-Id: Ieac05568477db4908cd4087714cf00a9addd1d20
This constant is not public yet. Continuous autofocus should
behave differently in still camera and camcorder. In camcorder,
lens movement may be more smooth. And the triggers to start a
new focus search may be different. If there is a need,
FOCUS_MODE_CONTINUOUS_PHOTO can be added in the future.
Change-Id: I05df9e491aca37829be3df92a73b952f26c86a4a
This fixes a bug that prevented the USB mass storage activity from closing
when USB is disconnected.
The bug was actually due to using == for a string compare instead of equals(),
but using the new notifications is a better solution than using battery events
since it will work for devices that do not charge over USB.
BUG: 3018954
Change-Id: Ia447974726a52cd865e59df5af79e828b5134b6c
Signed-off-by: Mike Lockwood <lockwood@android.com>
Don't wipe out the connected status every time we get a cellular status change.
Don't filter out disconnect event for wifi - we need them.
bug:3009923
Change-Id: I68cadac5f44d6eb4e0fe711fda7c5d218abb45bd
The main problem here was in the error recovery when we are waiting
for a process to start but it has failed for some reason. The code
was just setting mPendingBroadcast to null, but this would cause
an eventual ANR because the state was not set back to IDLE so we
would continue waiting for the broadcast without trying to restart
its process.
Now we set it to idle. We also need to reset the "nextReceiver"
index, so there is a new mPendingBroadcastRecvIndex variable holding
what it should be set back to.
While digging into this, I found a number of other lesser problems:
- There is a race when booting the system where we set mSystemReady
to true before restarting the upgrade processes. This could allow
a broadcast to happen between those two and its process to immediately
be removed. To fix this, there is a new mProcessesReady that is set
once we are truly ready to start launching processes.
- There were various places where we were calling sendBroadcastLocked()
without the flag to send only to receivers... if this is called before
mProcessesReady is set, then we would end up sticking any process for
the broadcast on the holding list to not get launched until later
(and hang up all broadcasts as they want for it). Now we always make
sure to set this appropriately.
- sendBroadcastInPackage() was not doing all of the validation that
sendBroadcast() does.
And of course a bunch of new debugging logs that were done in the
course of tracking this down.
Change-Id: I6134bbd94fdb73db8b693507b29499eae012d543
+fix the unknown call flash for answering an incoming call and
updating the screen if the background call got dropped.
+change the getFirstActiveBgCall to return the call if the state
is not IDLE. This will help to fix unknown flash if the background
call got dropped.
Change-Id: I9803ccebd919acbd5296e7dfde7dc5f29cc9f180
