Also fix Activity menu inflater when using the dark on light
theme wrapper to still be able to find onClick listeners.
Change-Id: Ie206db26d1df96041bc477804e476b02ad99dc9d
- 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
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
...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
...while listening to TTS example
This was a nice one. What was happening is that immediately upon
being created, the activity was starting another activity in a
different process. The second activity would never show, just
immediately exit. However the original activity had time to
pause and get into stopping itself before the second activity had
come back to the activity manager to say it was going away, resulting
in the activity manager asking the original activity to resume.
At this point the activity manager's state is that the second
activity is finishing and gone, and the original activity is
resumed. However in the app process the original activity is
still working on stopping itself, and it eventually completes
this and tells the activity manager. The activity manager now
changes its state to STOPPED, even though it is actually resumed
and that is the last thing it told it to be, and it is now
proceeding to set itself in that state.
This would result later in the activity manager sending an
unnecessary state change to the application. In the case of
the screen here, we next do a rotation change, the activity
manager thinks the current state is STOPPED not RESUMED, so it
tells the application to relaunch the activity in a new config
but not in the resumed state. Now it does the whole "start a
new temporary activity" thing again, at which point it tries
to pause the original activity again, and we have an unbalanced
onPause() call to the app and it falls over.
Change-Id: I38b680746f4c61ae30e7ce831e1de187adf60902
- Fading out recents first, then scaling up app
thumbnail
- Fade Recents out over 130ms
- Delay the window animation for 200ms first,
then animate for 200ms (previously we didn't delay
and then animated for 300ms)
Bug: 6390075
Change-Id: Ia8c753bf7ee03d2acef6eb2772b28d88fe10a682
- Remove the notion of channel from an application perspective
- Remove the use of DnsSd as part of API and add a protocol type to allow
future extensions
- Use the listener object as a handler for stop and unregister operations. Also,
we now allow multiple active discovery operations.
- Remove init/deinit operations in favour of setting up construction
Bug:6434844
Change-Id: Id15521d571aac9c4053d81184ad66dfc54f636de
Allow applications to transition from 0=>1+ visible menu items outside
of onCreatePanelMenu/onPreparePanel. Previously, having 0 visible items
at this point would require an invalidation of the options menu.
Bug 6452605
Change-Id: I6cbfc46d0e5ec42b8d78ee516e9b57fdeaf1a890
Propagate the return value from onNavigateUp as the result of
onMenuItemSelected. This fixes a bug where the action bar Up nav
button clicks would not be propagated to support lib FragmentActivity
or other activity subclasses that rely on processing otherwise
unhandled onMenuItemSelected events.
Change-Id: Id879dd1756ed06b8a7b720ebf0eae2a8ddc66ca8
Also don't retain the source bounds in recent tasks, since it
has no meaning there and it would be better when relaunching an
activity to have a new bounds set based on wherever it is now
being launched from.
Change-Id: Ia90c04ee98a888a7f725b038abe23d71e2b12800
...without onPause() in between
There was a bug in the handling of "always finish activities" where we
would go through destroying activities while in the middle of updating
the activity stack. This would result in the activity behind the
non-full-screen activity being created and then immediately destroyed,
which things were not expecting.
Change-Id: Idaa89089f7b1af7eb747d7b8f9f394beeb2d23fa
1. The dismiss implementaton in Dialog was posting a message
on the main thread to perform the real dismiss work. The
goal of this was to allow calling dismiss() from multiple
threads. The side effect of this is that when dialog fragment
is dismissed the dialog is not dimissed until the current
loop on the main thread is completed. However, during rotation
of the screen the current activity has to be restarted, hence
all fragments whould be removed. In the destruction process
the dialog grament requests from the dialog to dismiss but
since this is asynchromous, the code in
ActivityThread#handleDestroyActivity detects a leaking window
since the dialog window is still not removed and removes that
window. Now when the dialog removal message is processed on
the next loop we get an exception that the window has already
been removed. Now if Dialog#dismiss() is called from the
main thread the call goes right though otherwise a message is
posted.
bug:5911682
Change-Id: I449d6dd75a84c0ff29ea13dac7d163219cc38341
Bug #6436642
An app invoking dismiss() during a draw pass could cause crashes.
This change makes the code simpler too.
Change-Id: Iba89a8522e23d02f87697cfeec6cc713a1462669
Always hide contentText for BigTextStyle and InboxStyle.
Style cannot be used without specialization, it should be abstract.
Bug: 6428978
Bug: 6274137
Bug: 6317471
Change-Id: I21531a94494f891a058a477805b177e736b921cf
