* commit '6e4f886db034b954a305611cc71a10ff7d1c75ae':
docs: update sidenav to use <span> instead of <h2> for headings, under suspicion that the h2s are causing poor snippet extraction in search results
* commit 'b2d37b39a1bb48d9f9c5b45255c5df769b85d6ae':
docs: update sidenav to use <span> instead of <h2> for headings, under suspicion that the h2s are causing poor snippet extraction in search results
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
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
