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
when areas of the FB are undefined (transparent windows on top of
nothing), we clear those areas before composition.
however, it makes no sense to do this when the FB is not in use
(case where hwc handles all layers)
Bug: 5360529
Change-Id: If51bb669307e8419bbe1f3a89d1c88e0ec1f216c
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
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
we need to clear the whole framebuffer in that situation because
we can't trust the content of the FB when partial (fb preserving)
updates are used.
Bug: 5318492
Change-Id: I3f0e01b0fb665a34e44d88ad9f0f54a5d990060b
we need to clear the whole framebuffer in that situation because
we can't trust the content of the FB when partial (fb preserving)
updates are used.
Bug: 5318492
Change-Id: I3f0e01b0fb665a34e44d88ad9f0f54a5d990060b
