- Apply the correct crop rect at this point.
- Apply the correct position by taking into account the frame left/top.
- Don't directly apply the new values if the window is currently
animating, since we need to go through the whole animation step
to determine what the correct position is (taking into account
any transformations).
Change-Id: I15d79354d9779867c49c7c0880faccdead7b021d
- 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. During gesture detection we are not injecting the events we receive
since we do not want the accessibility focus to move as a result of
the hover event of the gesture. Because of that it was possible that
we consume all events since the user performs only gesture to navigate
resulting in the screen being off while the user is actively interacting
with the device. Now we are poking the user activity in the power
manager to keep the screen on.
bug:6485171
Change-Id: I06a09c5297f01bef5e20d471cee76fa7aae0c4fe
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
Change the thread priority for all disk measurement and statfs calls to
background priority.
Also move the measurement fully into the measurement task since it makes
more sense.
Bug: 6332097
Change-Id: Iafc2151313ad9b14117daf67e933dccd32f68d54
1. Since the API version has been finalized this change
updates the SDk version checks to use the JellyBean
verson number.
bug:5947249
Change-Id: Ie22fa7e18a7ea7b0c7077d80246a26c17f327ceb
The window manager now performs the crop internally, evaluating
it every animation from, to be able to update it along with
the surface position.
Change-Id: I960a2161b9defb6fba4840fa35aee4e411c39b32
1. The initial design was to have some accessibility gestures
being handled by the system if the gesture handling access
service does not consume the gesture. However, we are not
sure what a good default is and once we add a default handler
we cannot remove it since people may rely on it. Thus, we
take the simples approach and let the accessibility service
handle the gestures. If no gestures are handled the system
will work in explore by touch as before.
bug:5932640
Change-Id: I865a83549fa03b0141d27ce9713e9b7bb45a57b4
- During the transition, fade the bg to black
- Exiting activity fades to black
- Recents background no longer fades away, because
then it would fight against the fade to black
happening behind it
The CertBlacklister is a mechanism for allowing is to use gservices
to blacklist certs by serial number or public key.
Change-Id: Ie4b0c966a8a43c9823fb550c0b1691204f133ae7
This refactoring sets the stage for a follow-on change that
will make use additional functions of the power HAL.
Moved functionality from android.os.Power into PowerManagerService.
None of these functions make sense being called outside of the
system server. Moving them to the PowerManagerService makes it
easier to ensure that the power HAL is initialized exactly once.
Similarly, moved ShutdownThread out of the policy package and into
the services package where it can tie into the PowerManagerService
as needed.
Bug: 6435382
Change-Id: I958241bb124fb4410d96f5d5eb00ed68d60b29e5
