setupDataCallWithProtocol was introduced to introduce a
protocol parameter to setupDataCall without having to
modify its callers. This is not very useful, as there are
only two callers. Get rid of it and make setupDataCall take
the protocol parameter itself.
For now, hardcode IPv4 connectivity. When we add the
protocol field to ApnSettings, it will be fetched from
there.
Change-Id: I1a1adc616ffd9ac68be6911f054790da48e472d6
Special cases persistent processes to not allow their services to be
force stopped if the processes is crashing multiple times. Avoid the
annoying issue with the system bar going away if it is sometimes crashing.
Change-Id: Icf421f45e389827d612d70638030da755a8d3344
The writing of the persistent setting is async, but we should
still remember it so if somebody asks before the write completes
we give the right answer. Makes the read faster too.
bug:3312848
Change-Id: I864cb5f8d496d5bf9cbf0af9a71ca84da078f7c6
Due to a bug (fixed by 59163bf2f15e28712be6598144ae0fdb94dac52b),
libstagefright_yuv.so was actually not prelinked.
Change-Id: Idbc9b968708d0fc31a087d2e4f24398072d915e2
Some parts stubbed out but you can plug in a mouse and move
a green cursor around to interact with the UI.
Change-Id: I80d597a7f11d3bd92041890f74b3c77326975e6e
* commit '2967aa3e6060f582f166cdb334a0fb9ff0cb4759':
Improved ignore-backoff handling Allow a non-epidited ignore-backoff op to pass through an expidited backed off op.
* commit '672ebb61a755e4bbe60e4e884b1adadf186733b6':
Improved ignore-backoff handling Allow a non-epidited ignore-backoff op to pass through an expidited backed off op.
The previous change only hid the fragment when the transition animation
ended. But if there is no animation, the fragment would never be hidden.
This change adds an else clause that handles the non-animating case.
Change-Id: Ie35b2ae98cb5c21193dadefbef71b8542fcf5f7d
...android.app.Fragment.startActivityForResult(Fragment.java)
Make sure to remove all pending messages when AbsListView is detached
from its window.
But... that's not enough.
It turns out that when a fragment's views are animating away, they of
course don't get detached until after the animation is done. However
the fragment itself is immediately destroyed, leaving its live views
still going after that.
Here's a possible solution: when fragment manager initiates an animation
on a fragment whose views are being removed, it makes note of that so
it can hold off on destroying the fragment until the animation is over.
There are a lot of interesting race conditions here, if further operations
happen on the fragment while it is being animated. I think the code here
does something sensible, and it does seem to work for the situations I
have tested, but it is hard to know all of the edge cases that may happen.
Change-Id: I4490ce8862a9bb714c7ea54baca3072c62126388
Allow the hosting application to do what they want if the
control key is pressed. In particular, let our Browser
map Ctrl-arrow to back and forward.
bug:3270434
Change-Id: I2dfa648edbf5a0e48b674df5023182b4a70985f6
