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
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
setLaunchTime() was only being called from resumeTopActivityLaunched()
but also needed to be called from minimalResumeActivityLocked().
Fixes bug 11104901.
Change-Id: I35c994562dffaf75de014021c775e398224eb3a3
...bad cleanup of crashing processes
We now have a special path for crashing processes, to silently
clean up their state.
Also some tweaks to Log/Slog.wtf to get better stack crawl
summaries in APR.
Change-Id: Ieced26989907a6e7615b6fa033813fced78d7474
Stop the broadcast from being accidentally sent when PAC is in the process
of downloading / binding local proxy. Only send broadcast when valid port
is contained (i.e. sent by PacManager).
Bug: 11168706
Change-Id: I998711fcf0a6bd82bdef413726ec41317752a57b
If the keyguard is the wallpaper target the wallpaper cannot sit at
the bottom of the stack and must be directly beneath the keyguard.
Otherwise keep it at the bottom of the window stack.
App animations when the keyguard is showing should not be disabled if
the keyguard is also animating.
Fixes bug 10858941.
Fixes bug 10932680.
Change-Id: I8399837f6510ea16003f68b165e67439f3571ef4
Migrate transient bar mode to IMMERSIVE_STICKY, and
introduce new behavior for IMMERSIVE: namely the
opaque bars are revealed by clearing the flags on swipe.
Remove low-profile optimization that confuses api demos
and other apps using low-profile as a signal.
TransientNavigationConfirmation renamed to
ImmersiveModeConfirmation, and its associated resources,
since the confirmation is now shown when the nav bar is
shown in either of the two immersive modes.
Remove unused Toast.makeBar and associated hidden framework
bits now that the confirmation uses a cling instead.
Bug:11062108
Change-Id: Iae49d31973940b9bee9f5b1827756db5eaa76aa3
The CL that ensured that a dying task must be in front of the user
(ag/374996) only checked that the task was at the top of /a/ stack,
not on top of the frontmost stack. This checks the stack for being
frontmost before switching to home.
Fixes bug 11208762.
Change-Id: I43f6d380e7a880ec19db03711ada6c7437e15f73
We have become too aggressive about not allowing windows to draw while windw
animations are running, basically not allowing any drawing in any window when
there is any window animation. So if you did a relayout while the status bars
were being animated, your window would stop drawing until that status bar
animation was complete.
This change relaxes those rules in two ways:
- A particular window will only be told to stop updating when *it* is
currently involved in a window animation. So animations in status bars
will not stop app windows from update, and vice versa.
- If a window receives input events while it is in the "do not update"
state, we will immediately terminate that state and start allowing it to
draw. If the user is actually interacting with a window, we don't want
to wait to show feedback.
Change-Id: I72574eec048aee53115b46a78686cf27f42c42f7
This commit prevents a system_server crash when applications attempt
to use the fused location provider on systems that do not have a
network location provider available.
Bug: 10845061
Change-Id: I85b33806e05566e8b68ee2ccc401b1c565fd7b9a
The last refactoring of how the print dialog activity is started moved
the code that creates the pending intent from the spooler which is a
per user app to the system process but failed to create the intent
for the right user. Also the code in the print manager service that
puts a notification for a newly isntalled print service was not taking
into account the current user.
bug:11199393
Change-Id: I64ecf9dc1457ec4d58cc1a62e53735bb0793a003
1. The getActivePrintJobs() method in print service is designed to return
the active print job i.e. ones scheduled to be processed by the print
service. Now the correct list is returned.
2. The listeners for observing the state of print jobs may be called even
after being unregistered. Ex: state change occurs and we schedule a
message on the app's main thread to make the notificaion. Now the app
unregisretes the callback and on the next loop the notification message
is handled.
bug:11200258
Change-Id: I4a497b5c9a7287a22023cafe41ce966d14300ca6
