- 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
Finishing tasks with an activity affinity was failing if the
activity was found at index 0. This fixes the loop condition.
Change-Id: If2e0d294e3e4493bca8b7efd40f24adaf2eb0b6f
...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
Deliver new intents to an existing parent from the calling uid obtained from
the applicationInfo instead of the process record, since the process record
might be dead.
Stoopid monkeys.
Bug 6328725
Change-Id: I4371a5705ccd7004f0dfe11da7c48d1563fb8dac
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
BaseStatusBar uses this to launch activities over the insecure
lockscreen, so clear identity.
Bug: 6414983
Change-Id: Idf578923285ee1344e6e13e7f51e17a5f2005c75
...foreground app when the device was put to sleep
This is because of activities being kept in the stopped state
while the lock screen is shown, so we never get to the point of
it becoming visible again to know to proceed.
Just at this point consider the lock screen hidden so the
activity can be resumed and run as normal; the whole point of
this is to soon hide the lock screen, anyway.
Change-Id: I3a713a2f87b8e4412ff66724c051f09a2675be00
Third party apps now can't get access to the extras of the
intents associated with tasks, to keep private data in them
from leaking out.
Change-Id: I95af9e181ac42557bc8b981807e7ddd266a88d0e
Step to Reproduce
1) Turn off device’s screen. (Sleep mode)
2) Kill any process.
A. Engineer Version: kill [PID]
B. User Version: am force-stop [Package Name]
3) Foreground activity proceed [Resume] and [Pause] consecutively.
Reason: Since ICS version, activity goes to stopped status when screen turns off.
stopIfSleepingLocked( ) makes activity to stopped status but, pauseIfSleepingLocked( ) was used in GB
and, activity keep paused status and, this problem did not occur.
This change give effect to resuming activity when any process was killed.
Because, resume is proceed without exception for activity status.
The exception only filtered for [ActivityState.PAUSED] in sleep or shutdown mode.
and, resume complete flow when activity status was [ActivityState.STOPPED].
Solution for this issue:
We think that exception’s condition have to change if stopped activity status is intended in sleep mode.
According to activity life cycle, activity can not resume from stop status.
Also check [ActivityState.STOPPING]. :)
Change-Id: Icca3366ac30ffa3b18f6e2393e4d7309089ef26a
Add permissions for various things it pokes. Create new permission
to control launching non-exported activities from recents. Hidden
API to relax WallpaperService checks.
Change-Id: I547fdcd7c213dd153ae101533ce7c56cd8f86a0d
These now do something reasonable when performing transitions
across two activities that are both on top of the wallpaper.
Fixed computation of the pivot point of the animations.
Fixed issue where the recents panel was considered a status
bar element for purposes of deciding if the animating elements
are obscured by the status bar, which would result in us not
running the animation correctly.
Change-Id: I4b9b588b80243463e6f087a9703ee886ee281630
An intent is launched in a singleton process if the process is persistent
and the resolved activity/service/etc is not requested to run in a different
process.
Change-Id: I1463e73a76bc8bde4185f9cf4395edb47515841d
Tell the activity manager when the lock screen is shown, so it
can keep itself (mostly) in sleep mode during this time, having
the foreground actvities remain in their stopped state.
Change-Id: I71c86d3298f23a98014d7ae36fd540c9df9a64e6
Due to the step to query the users, dumpsys was crashing when run
as non-root. Clearing the calling identity after checking perms
fixes this.
Bug: 6311443
Change-Id: I0b0bca5c7305cea19adc772b3bfec34c16bb24c4
We now allow processes that currently have stopping activities to
be managed as if they were done stopping, so that memory trimming
can be done before the process goes to the background. Hopefully
this will reduce cases where the processes goes to the background
and immediately gets killed, but wouldn't have had to be killed if
it had a chance to trim its memory.
Also change window memory trimming to always do the aggressive
trimming when memory is critical, even if not on a low-end device.
And tweak web view trimming to not trim for foreground UI events.
Change-Id: I241b3152b52d09757bd14a202477cf69c9b78786
The ANR dumping code was reusing the shared StringBuilder while
not holding the ActivityManagerService lock. As a result, other
threads could sweep in and clobber the ANR information.
We don't want to hold the lock here, so just create a new StringBuilder.
Change-Id: I0d91af55f5c123102cfab2cd97035491efed59c0
Wakelock usage for the purpose of sending an alarm broadcast is now
attributed to the application which posted the alarm, not to the OS.
Bug 5911317
Change-Id: I8cb79c3bd5db467388716ab68285f4ab0bfe468b
Promote navigation helpers from the support library to the core
platform.
The support library's meta-data element has been replaced with a
first-class parentActivityName attribute. This attribute is valid
on both activity and activity-alias elements. An activity-alias
will inherit the target activity's parentActivityName if one is
not explicitly specified.
Automatic Up navigation for Activities
Add the public method onNavigateUp() to Activity. The default
implementation will use the metadata supplied in the manifest about an
activity's hierarchical parent (parentActivityName) to do the right
thing.
If any activities in the parent chain require special Intent
arguments, the Activity subclass should override onNavigateUp() to
properly implement Up navigation for the app, supplying such arguments
as needed.
If automatic Up navigation within the same task can't find an activity
matching the supplied intent in the current task stack, it will act as
an in-app "home" and return to the root activity (presumably the app's
front page) in that task. (From this state, pressing "back" with
default behavior will return to the launcher.)
Change-Id: If163e27e59587f7af36975a09c986cb117ec3bc6
