This cl ensures that we immediately route the user to the add account
activity if they don't have an account and their is only one relevant
account type. Also reordered the setContent logic to reduce flicker.
Note that as of this CL there is still some flicker remaining when
launching G+ without an account. But it appears to be fixed in other
apps.
Bug: 6455975
Change-Id: I91e33b4fb9618a31765b4a8651334b1c52640828
Bug: 6505722
When we scroll the base layer we do so by calling scrollTo on the view,
which handles all the scrollbar logic for us. Remove the custom keep alive
code which floods the handler queue, as well as remove the unnecessary
invalidate and awakenScrollbar calls (View does that for us)
Change-Id: Ia2503c549a22ec71d99295fe62b676fecc367ea3
This makes a noticeable improvement in cases where applications
post messages that need to be processed between animation frames.
Bug: 6418353
Change-Id: If225742e37aeaf3f0ca9710f9bf43dbb03bcde12
- Horizontal layout
- At most 2 are shown
- Tombstones are now shown (if the intent is null, the
button is disabled; use it for quick feedback of an
action's effect)
Bug: 6418617 (tombstones)
Bug: 6482237 (action separators)
Change-Id: Ie0c613006227bbfe1c0ec6eab1cda4f3782a05f2
1. View is checking if the accessibility focus is its
descendant it clears the accessibility focus state
in ViewRootImpl. The check in View was missing the
case that the descendant may be the view itself. In
such a case we want the normal clearing code to run.
2. The check whether a view has iterable text for
accessibility was inverted and text nav was not
working.
Change-Id: I1a13b6809fb7f205fff76ca09cd449179d06e530
Bug #6485955
If an invalidate gets scheduled right before the EGL surface is destroyed,
the next draw pass is done in software. This causes the software renderer
to connect to the surface forever which prevents the hardware renderer
from coming back when the screen is turned back on.
The fix here is to ignore the draw request when hw acceleration is requested
but not yet available. Proper software fallback will still happen when an
error is encountered with hardware rendering (in which case hw acceleration
will not be marked as requested anymore.)
Change-Id: I1edc4a51c8dd38240aa2345092a18a081a756fc1
1. The prefetcher of accessibility nodes infos was not folloing
the childForAccessibility relationship when finding the views
whose node infos to prefetch.
2. NumberPicker was not reporting the correct parent.
bug:6471710
Change-Id: Ia7ad5dd031fb4b3816dfe630d5212201cfafa236
Bug: 6478079
Pointer assignment instead of copy was resulting in mValues being cleared
on next launch, since mValues became the same pointer as mNewValues.
Change-Id: I91014948e4f48056474b3ab31aab6d35e0ad69ca
task.
When navigating up from a different task, if the current activity has
a result set only finish the current activity instead of trying
finishAffinity. Log this so that developers know why this behavior is
happening.
Bug 6465336
Change-Id: Ic7cec6f0c0d5861296091e2aea9344309f5fc600
- Add documentation on "television" UI mode.
- Tweak new documentation and implementation around propagating
URI grants through choosers.
- Add new activity launch flag for closing system dialogs.
Change-Id: I978c05f0dc3d16e1c55d43631828b9efa6335b19
...FragmentManagerImpl.restoreAllState
This was a bug related to the difference between the pre- and post-HC
behavior of onSaveInstanceState(). Prior to HC, state was saved
before calling onPause(). Starting with HC, it is saved between
onPause() and onStop(). To maintain compatibility with existing
applications, there is a check in ActivityThread for pre-HC to in
that case emulate the behavior of old applications, still calling
onSaveInstanceState() before onPause() but using the state later.
One of the special cases we had to deal with in the old model of
saving state before pausing was restarting an activity that is
already paused.
Consider, for example: you have two activities on screen, the one on
top not fullscreen so you can see the one behind. The top activity
is resumed, the behind activity is paused. In the pre-HC world, the
behind activity would have already had its state saved.
Now you rotate the screen, and we need to restart the activities.
We need to destroy the behind activity and create a new instance,
but the new instance has to end up in the paused state. To
accompish this, we restart it with a flag saying that it should
end up paused. For the pre-HC world, since it ends up paused,
we need to make sure we still have its instance state kept around
in case we need it because we can't regenerate it (since it is
already paused).
So that is what the changed code here is doing. It goes through
the normal create/start/resume steps, but holds on to the current
saved state so that it isn't lost when resume clears it, and then
puts the activity back to paused and stuffs that old saved state
back in to it.
The problem is that this code was doing it for every application,
even HC apps. So we end up in a bad state, when a HC app has its
saved state sitting there as if it had been saved, even though it
is only paused. Now if we go to restart the activity again, instead
of asking it for a new saved state (as we should for a HC app as
part of stopping it), we just re-use the existing saved state again.
Now this wouldn't generally be a huge problem. Worst case, when we
restart the activity yet again we are just instantiating it from
the same saved state as we used last time, dropping whatever changes
may have happened in-between. Who cares? All it has been doing is
sitting there in the background, visible to the user, but not something
they can interact with. If the activity made changes to its
fragments, those changes will be lost, and we will restore it from
the older state.
However... if one of those fragements is a retained fragment, this
will *not* appear in the saved state, but actually be retained across
each activity instance. And now we have a problem: if the retained
fragments are changed during this time, the next activity instance
will be created from the most recent state for the retained fragments,
but the older state for everyting else. If these are inconsistent...
wham, dead app.
To fix this, just don't keep the saved state for HC apps.
Also includes a small optimization to ActivityStack to not push
the home screen to the front redundantly.
Change-Id: Ic3900b12940de25cdd7c5fb9a2a28fb1f4c6cd1a
1. Added support for accessibility scroll action to
some widgets that are scrollable.
2. Making the super call when handling an accessibility
action in the views to call super first to allow
an accessibility delegate to intercept the call.
bug:5932640
Change-Id: I5eb37d64bf9fba1d5c596981132e0df717e2a18a
