The old approach has a problem with the original application's
recent tasks entry disappearing (this is probably a bug in the
platform). Update to an alternative approach that does work.
Change-Id: I15e582eff8c77cc22628f7b099e9f04eb5bfbce7
Because the NetworkInfo included in CONNECTIVITY_ACTION broadcast
extra does not reflect the state applicable to the calling UID, and
the last sticky broadcast may have stale state, transition to calling
ConnectivityManager.getActiveNetworkInfo() directly.
Change-Id: I86b316fbedd0273585ad5f1248b091bc3a3a5520
EffectModule::addHandle and Client::heap() were declared incorrectly.
As a parameter, an sp<> should be & for efficiency, and for input
parameters it should also be const to protect the caller's value.
But as a return value, an sp<> should have neither const or &. The "e"
in "return e;" might be located on the stack, and if there is "&" then
the caller would see the address of a variable which no longer exists.
Also, an & would make it hard to do "return 0;".
A "const" without & is meaningless in the return type.
(In this particular case, the "e" is a member field, so it was safe.)
Change-Id: I3df5f294214eb15a9d4d596c6d5ef29de97b5c27
When a view is becoming VISIBLE or INVISIBLE in a container with a
LayoutTransition, animations run to fade the view in and out and also
to run 'changing' animations on the view's other siblings. This logic
also cancels any running 'changin' animations to account for new ones
running.
However, in the specific case of INVISIBLE changes, there will be no
layout changes in the container - layout has already accounted for that
view (unlike in the case of GONE views); the visibility is just a matter of
drawing the view (or not). Therefore, we're canceling 'changing' animations
that should continue running and not replacing them with any other animations,
since new animations would only be started on layout chnages which are not
forthcoming.
One artifact seen from this bug is that the navigation bar buttons sometimes
disappear when changing orientation. This is because the menu button may
toggle between VISIBLE and INVISIBLE, causing animations on the other
buttons to get canceled, which leaves those views in a completely wrong
state.
The right thing to do is to avoid canceling in-process 'changing' animations
and to skip the logic of setting up new 'changing' animations which won't fire
anyway.
There is some minor API work in here because we did not previously have the
necessary information in LayoutTransition to know whether a view was being
hidden or shown to/from the INVISIBLE state.
Issue #5911213: LayoutTransitions ending in an odd state
Change-Id: I5c60c8583c8ea08965727b4ef17b550c40a3882c
The test here is partly fixed by Change I38c54265. However, the test
itself still needs to be fixed as local numbers in US never starts with
a '1'.
Bug: 5599741
Change-Id: I3a3961331961f4f535d30dec884babdb32e8b67b
This extension is always added to the GL_EXTENSIONS
extension string for the current GL context, regardless
of if it's supported by the h/w driver.
The extension itself will be handled by GLES_trace (eventually),
when GLES_trace is not enabled, it'll result to a no-op.
If the h/w implementation has this extension, we'll call that version
instead of our dummy version.
Change-Id: Ie5dd3387c4d45cd5ed5f03b73bda6045620a96bc
--latency-clear [name]
clears the latency data for the specified layer or for
all layers if none is specified
--list
prints the list of all layers regardless of their visibility
Change-Id: I7c07ae020f838c173b98ee50f3fb3e93da78acbb
Bug 5556478
Launcher pre-populates its all apps and widget pages with their
content, which includes text. The layout calls some onMeasure methods
that trigger TextView's registerForPreDraw(), which in turns adds a
listener in the ViewTreeObserver.
However, some of these pages may never be actually displayed, leaving
the listeners in the list since onDraw() is never called.
As a result, every frame displayed by launcher is slowned down by this
array copy of 6-18 listeners.
The problem is not Launcher specific since other applications may use
a similar caching mechanism.
The solution is to unsubscribe the listener in onPreDraw.
The drawback is that several successive calls to registerForPreDraw() will
add/remove the some listener object. However, these calls are rare and are
relatively cheap since we're just adding the object in and out of an
ArrayList which should not need to change its size.
Change-Id: Ifb65655a27e302d31a2ad622d18f839aec99689e
Don't check that pointer is non-NULL before delete.
Don't leave deleted member fields non-NULL, except in a destructor,
since it could be misleading in a dump or debugger. (mRsmpOutBuffer)
Change-Id: Ic0492a6b752f74a67f4c96dfb89ca2de4e69eecf
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 remove defaults in startToneCommand(), they're not needed and the
default for tone type was nonsense.
Change-Id: I70fa8cee4f3dbb8c66ceb3719c8d3d2f447f05b9
- also clean some destructors (was not quite compulsory because
they are related to some Singletons)
Change-Id: I3091cac7b38628cda593d72570ba7a5d7ea2a15c
