We need to be able to perform very lengthy operations on some threads
(e.g. the I/O thread responsible for installing multi-gigabyte APKs) but
still have long-run deadlock/hang detection applied to those threads.
Previously the watchdog mechanism applied the same policy to all
monitored threads: unresponsive after 60 seconds => restart the system.
Now, each monitored entity can have its own independent timeout after
which the watchdog declares deadlock and restarts the runtime. The
halfway-finished intermediate thread stacks are dumped based on the
specific entity's declared timeout, not the global 30 second checking
interval.
With that new mechanism in place, the Package Manager's lengthy-I/O
thread watchdog timeout is raised to 10 minutes.
Bug 11278188
Change-Id: I512599260009c31416b2385f778681e5b9597f05
The previous jank improvement only worked when closing
an app, not when bringing one forward (hitting home button).
This should cover the specific case that is being missed: Having the
Home task being brought to front over a translucent window, with
a wallpaper behind both tasks.
bug:11253262
Change-Id: I200ef6fe2dda8d9ab4e1f82059b4f888c59007f4
When a non-fullscreen task over home launches another non-fullscreen
task then the home task might not be displayed. Looking all the way
down the task stacks until reaching a visible, fullscreen activity or
home provides the right information.
Fixes bug 11273803.
Change-Id: I8dab0956c1cda06ddb7850ea3ffac7f6a223c6ad
Minor changes for dumping stack traces:
- Print the native traces right after foreground/persistent apps
- Also include mediaserver, sdcard, and surfaceflinger in traces
Bug: 11321322
Change-Id: Ic09b7da316a5f197dda0ac3bde06f75574cc2166
The android package is now a special case, not being added to the package list
when creating a multi-process component. There is no need, since this package
is actually the framework itself which must be loaded in every process.
Also cleaned up some of the procstats dump output to help see what is going
on here.
Change-Id: If65d35ecd562f3154bdebfded69c454af6ce8c96
Because properly continuing permission grants post-OTA has changed
policy to include privilege considerations based on install location,
make sure that we re-evaluate when we determine that the apk has
moved from its pre-OTA location.
Bug 11271490
Change-Id: I6c09986e2851a67504268b289932588457c05dfc
The WindowManagerService member mLowerWallpaperTarget is not stable
throughout an app transition. Relying on it to be stable causes the
intra-wallpaper animation to start out right but after the windows
have been relayed out there is no longer a lower wallpaper target.
This causes the wallpaper to start tracking the animation of the
current wallpaper target rather than remain stable.
Switching to a new variable that saves the state of wallpaper
animation at the start of the animation fixes bug 11240590.
Change-Id: I336a59c47665fcf61019f567b8663956ff0e4940
When finishing or stopping an activity the code was automatically
refocusing to the next activity on the same stack independent of the
task's onTopOfHome flag. When the activity eventually finished or
stopped it would then honor the onTopOfHome flag.
This fix examines the onTopOfHome flag and arranges the focus
correctly if home is the next activity to run.
Fixes bug 11318263.
Change-Id: I73a8f5e82de04b01acaffe366b085f9e475e1451
There were circumstances where mFocusedStack could be assigned the
home stack. If this were ever to occur then all subsequent tasks would
be put on the home stack. This fix ensures that there is no way that
mFocusedStack will ever be assigned to the home task.
Fixes bug 11271189.
Change-Id: I7ddd9b6bcbf2787cbe2f44b461ad057ae2241f00
The possibility existed that an activity was set to a task that it was
already being set to. If that were to happen, and it was the only
activity in the only task of the stack the stack would be deleted.
This fixes that situation and logs it as well to confirm that it does
fix bug 11272935. Logging to be deleted upon successful monkey run
exhibiting the log.
Change-Id: I436fdcc9a3734adad81d3ef90f29b93b3ac4dfcd
The existing code wasn't retaining the requested window bounds, if any,
and so could wind up rebatching alarms into much longer potential
delivery windows than originally demanded by the caller. This could
wind up delivering alarms outside their designated windows entirely.
Bug 11324357
Change-Id: I4d418cd08702e397b3c7692b412d4bf51d5d9e4b
When a translucent window is closing, the transition
animation to Launcher is janky because Launcher is
expected to be 'opening' but it has always been open
underneath the translucent window. Therefore, the
animation applied to the translucent app appears
janky.
bug:11253262
Change-Id: I9b6af3291d119e6927401f63785b12f25573f4eb
Also disables all setting of PAC networks through the internal AsyncChannel
methods. PAC can only be saved through addOrUpdateNetwork for permission
checks.
Bug: 11316946
Change-Id: I51016b578080c342a5e5d536ea9a3fdd4fe16644
In this case:
1. Privileged system app FOO is overlain by an installed update,
2. FOO was replaced during an OTA,
3. The new in-system FOO introduced new privileged permission requests
that had not been requested by the original FOO,
4. the update version of FOO still had a higher version code than
the new FOO on the system disk, and
5. the update version of FOO had been requesting these same (newly-
added-to-system-apk) permissions all along;
then the newly-added privileged permission requests were incorrectly being
refused. FOO should be able to use any privileged permission used by the
APK sited on the system disk; but instead, it was only being granted the
permissions used by the *original* version of FOO, even though the system
FOO now attempted to use them.
Still with me?
The fix is to (a) properly track privileged-install state when processing
known-to-be-hidden system packages, and (b) to tie the semantics of the
permission grant more explicitly to that evaluated state, rather than
using the prior (rather fragile) fixed-up privilege calculation applied
to the overlain apk's parse records.
Bug 11271490
Change-Id: Id8a45d667e52f3b5d18109e3620d5865f85bb9c9
When the app spends more than half a second responding to a touch
event, the input dispatch eventually decides to stop sending it
events until it catches up. (This is when the ANR clock starts.)
However, due to a bug in the timing logic, if the app eventually
does respond again we would resume delivery but only send one
event at a time until the queue was completely drained again.
This meant it could take a long time to catch up and process all
events.
The problem is that we were comparing the current time with the
waiting event time. So when events became older than half a second,
we would simply stop streaming and end up serialized.
This change fixes the timing logic such that the streaming timeout
is based on the delivery time of the waiting event rather than
the event time itself. Now we only stop streaming when it has
been over half a second since the waiting event was delivered
so we resume streaming immediately as soon as some waiting
events are handled.
Bug: 11278743
Change-Id: Ic8c68ee372a07f7caa4168eefcabf9b8a8ad5d87
Needed to do an http post instead of a get for one carrier.
Do this by putting an auto-submitting form in the data to be
interpreted as a html doc by the browser. The ACTION_VIEW
intent only works on http uri, but by specifying ACTION_MAIN/
CATEGORY_APP_BROWSER we could use data:text/html.
bug:11168810
Change-Id: Ifd33e1c3c7f9f40b6add39e446e6a7d7cde22549
Include volume UUID in generated document IDs to uniquely identify
volumes over time. Show volume label to users. Watch for mount
changes to update available roots.
Bug: 11175082
Change-Id: Ia151bde768587468efde0c1d97a740b5353d1582
vold now parse out UUID and label for inserted physical devices,
and reports them to framework. Add these to hidden StorageVolume
class for use by DocumentsUI and MediaProvider.
Remove last JNI method in FileUtils!
Bug: 11175082
Change-Id: I1cfcd1ade61767b103f693319ea2600008ee2e3c
Two problems addressed here:
- If a call to startActivity() comes in on an activity that is finishing, we can
end up putting the new activity in a stack that isn't actually in use any more
(if the finishing activity is the last one on that stack). This is a bad case,
anyway, so if this happen the treat it as not being called on an existing
activity and switch to NEW_TASK to find a task for it.
- There was a bug in handling PACKAGE_CHANGE broadcasts that would result in the
app's processes being killed, even though the cleanup through the activities
was done. This could leave the activity stack in a bad state. Fix this to
correctly provide an app id for the changing package so that its processes are
killed.
Change-Id: Iece04e0cf95025c3d30353d68bf3d14fd39d44c3
We're getting some false positive results on this check and
while it was coded to try 3 times given sufficient independent addrs
the default url resolves to a single address so we'd just try once.
Rework to try again even with fewer urls to try to reduce the false
positives.
Also adds a random query param to fool proxies into not caching.
bug:9972012
Change-Id: Ib719f40ec612065ca6bcd919549fc1164506d35a
