The current implementation of global proxy is dead,
and it will be removed completely in separate changes.
Change-Id: I54f6b3960f761483d28d808e99db4c71c9c0348d
The text of the dumped output can potentially include an email address;
we don't want random code to be able to read it.
Bug 5389201
Change-Id: If84886357a36b7015878e4d72017abba83b4c511
Some services have info that is not readily available any other way. Add
a permission check to those services.
Bug: 5389201
Change-Id: I5a9724ec89e1c11ef7813eeb52a6a05b3ea92af5
Change Ife82a8d8 broke IPv6 on wifi. Change I4e3a69ea is
an alternate approach that does not require any framework
changes.
Bug: 5284168
Change-Id: Ib6e002aa23700adc71051cf6b76860545497dbf4
This change ensures the wallpaper is rendered into an opaque surface
which avoids a glClear() in SurfaceFlinger. This should save quite
a bit of work on every frame when panning the workspace in launcher.
Change-Id: Id43d3498a54c2d60ec4ee3377c92ef79bff55bc1
This change ensures the wallpaper is rendered into an opaque surface
which avoids a glClear() in SurfaceFlinger. This should save quite
a bit of work on every frame when panning the workspace in launcher.
Change-Id: I9c1b8c324edf29826d5dbb1fb39d883e43375310
Casualty of the recent refactoring: in this particular error case,
the restore sequence wasn't being directed into the finalization
state. Fixes bug 5336295.
Change-Id: Ibf5570cd1003e123da8b561685de8479663340ce
Bug: 4981385
Changed the orientation listener to notify the policy whenever
its proposed orientation changes, and changes the window manager
to notify the orientation listener when the actual orientation
changes. This allows us to better handle the case where the
policy has rejected a given proposal at one time (because the
current application forced orientation) but might choose
to accept the same proposal at another time.
It's important that the proposal always be up to date. A proposal
becomes irrelevant as soon as the phone posture changes such
that we can no longer determine the orientation with confidence
(such as when a device is placed flat on a table).
Simplified the orientation filtering. Now we just wait 200ms
for the device to be still before issuing a proposal. The idea
is that if the device is moving around a lot, we assume that
the device is being picked up or put down or otherwise in
the process of being moved. We don't want to change the rotation
until that's all settled down. However, we do want to tolerate
a certain amount of environmental noise.
(The previous confidence algorithm was also designed along
these lines but it was less direct about waiting for things
to settle. Instead it simply made orientation changes take
longer than usual while unsettled, but the extra delay was often
too much or too little. This one should be easier to tune.)
Change-Id: I09e6befea1f0994b6b15d424f3182859c0d9a530
* Verifiers can be specified in the AndroidManifest.xml
* Those verifiers can respond to the new Intent action
* PackageManager API for those verifiers: verifyPendingInstall
Change-Id: I4892bce2e6984871e6e93c60a1ca0dae145f5df5
...Should Skip Unsecure Lockscreen (ICS)
Also while I am in there, clean up logging of intent objects to include
even less sensitive information, while showing the true Intent in dump
output (since apps can't get to that).
Change-Id: I35fed714645b21e4304ba38a11ebb9c4c963538e
The message when something is not an APK that is submitted for dexopt is
not extremely helpful. Make it more precise and remove the useless
traceback.
Change-Id: Ibb34b2b2c10ee28ea98662c3f6fd070529cf8c4f
If the app had activities still finishing, when we checked whether it was
now stopped we would get told no. Also some other improvements:
- Schedule an idle as part of the force stop, to get any finishing
activities out of the stack soon rather than waiting for some activity
to idle.
- Don't filter out stopped system apps. This is dangerous because
system apps may have no way for the user to explicitly launch them,
so they could get put into a stopped state for which there is no way
to get them out. Also if the user really wants a system app to not
run, the new disabling mechanism is more appropriate.
Change-Id: I34003f21dac29e2ca0f66a23b88c710de41bab99
Stop guessing based on the connectivity of the default route and use the correct
v4/v6 proto for your pid.
bug:5284168
Change-Id: Ife82a8d8e54c0ace2bc9e8a624b11d29a4e285e2
Watch for changes to telephony network subtype, and update iface
mapping to persist stats under correct type. Update network stats
before removing tethering NAT rules.
Skip recording that would create empty historical buckets. Query UID
stats before iface stats to always skew positive when counters are
actively rolling forward.
Bug: 5360042, 5359860, 5335674, 5334448
Change-Id: I8aa37b568e8ffb70647218aa1aff5195d3e44d5a
Be more explicit about initialization -- power manager never sends
screen update when first initializing, phone window manager retreives
current screen state and applies that itself when initializing.
Change-Id: I8294ed36d700e186c1637754df8c8183721c15dd
Bug: 4981385
Simplify the orientation changing code path in the
WindowManager. Instead of the policy calling setRotation()
when the sensor determined orientation changes, it calls
updateRotation(), which figures everything out. For the most
part, the rotation actually passed to setRotation() was
more or less ignored and just added confusion, particularly
when handling deferred orientation changes.
Ensure that 180 degree rotations are disallowed even when
the application specifies SCREEN_ORIENTATION_SENSOR_*.
These rotations are only enabled when docked upside-down for
some reason or when the application specifies
SCREEN_ORIENTATION_FULL_SENSOR.
Ensure that special modes like HDMI connected, lid switch,
dock and rotation lock all cause the sensor to be ignored
even when the application asks for sensor-based orientation
changes. The sensor is not relevant in these modes because
some external factor (or the user) is determining the
preferred rotation.
Currently, applications can still override the preferred
rotation even when there are special modes in play that
might say otherwise. We could tweak this so that some
special modes trump application choices completely
(resulting in a letter-boxed application, perhaps).
I tested this sort of tweak (not included in the patch)
and it seems to work fine, including transitions between
applications with varying orientation.
Delete dead code related to animFlags.
Handle pausing/resuming orientation changes more precisely.
Ensure that a deferred orientation change is performed when
a drag completes, even if endDragLw() is not called because the
drag was aborted before the drop happened. We pause
the orientation change in register() and resume in unregister()
because those methods appear to always be called as needed.
Change-Id: If0a31de3d057251e581fdee64819f2b19e676e9a
Provider was not being removed from the class map because it was using
the wrong key. D'oh.
Also a little cleanup.
Change-Id: I318e8b1a265318ac1474e0a7f14f27f89f357505
The keyguard/window manager recently got a facility to report when it is
okay to turn the screen on, when it knows the lock screen is displayed.
The power manager was using this wrong, just using it to drive the
flags given to the input system. Duh.
This change now uses the information to determine when to turn the screen
brightness up from 0. For an OLED screen, this is the time when the
user can actually see anything on the screen.
For LCD screens this may not be optimal, because the LCD may start running
before its backlight is turned on, so if you look carefully you may see
stuff before it is lit up. On the other hand, it is good to turn on the
display as early as possible (before waiting for the keyguard) because it
can take a little bit of time to get that and the touch screen going. By
only waiting on the display brightness, we allow turning on the screen
in the kernel to proceed in parallel with ensuring the keyguard is displayed.
Change-Id: I7ee4ce19fd4efd5b51872b855af6263f53cd6c30
