The power manager sends SCREEN_ON and SCREEN_OFF broadcasts
purely based on the current wakefulness state. In particular,
when the system is awake, we consider the screen to be on even
if the screen may actually be off due to the proximity sensor
or some other condition. Likewise when the system is dozing
or asleep, we consider the screen to be off although technically
it may still be on and dozing.
This behavior is maintained for compatibility with applications
that interpret screen on / off as an indicator of user presence.
As it happened, the value of PowerManager.isScreenOn() did not
always match the state indicated by the broadcasts under certain
situations. Instead, it was based on the desired screen state.
These states used to be closely correlated but the addition
of doze mode causes them to diverge in meaning.
One consequence is that wake events from input devices might not
always wake the device from sleep unless the display's power
state was actually DOZING or OFF even if the power manager's
wakefulness was already DOZING or ASLEEP. This is now fixed.
Change-Id: Ie819c6d2c5a9ffaaf3101c5dee93ff72e9bc9f30
Various authenticator results such as getAuthToken and addAccount might
result in an Intent returned to the AccountManager caller. A malicious
authenticator could exploit the fact that the Settings are a system app,
lead the user to launch add account for their account type and thus get
Settings to use the intent to start some arbitrary third parties Activity.
The fix is to make sure that the UID of the app associated with Activity
to be launched by the supplied intent and the Authenticators UID share
the same signature. This means that an authenticator implementer can only
exploit apps they control.
This is a backport of 5bab9daf3c
Bug: 7699048
Change-Id: Ifed345c2fc20020d55fa2cab1f2f7ea509ea09b2
Various authenticator results such as getAuthToken and addAccount might
result in an Intent returned to the AccountManager caller. A malicious
authenticator could exploit the fact that the Settings are a system app,
lead the user to launch add account for their account type and thus get
Settings to use the intent to start some arbitrary third parties Activity.
The fix is to make sure that the UID of the app associated with Activity
to be launched by the supplied intent and the Authenticators UID share
the same signature. This means that an authenticator implementer can only
exploit apps they control.
Bug: 7699048
Change-Id: I34330454c341e6a8422ca1ed3b390466a0feedce
(cherry picked from commit 5bab9daf3c)
Normally we do not wake the device when the internal touch screen is
touched. This behavior can now be configured by setting a property
in the input device configuration file. Add the following line to
the IDC file to enable an initial touch to wake the device from sleep.
touch.wake = 1
Change-Id: Ifd6d4f51afacd30d85f475725a66e6fcccde9cbb
Interface of Surface class changed.
To reflect the change for EGL14, add producerControlledByApp flag.
Similar change can be seen in 0fa257fe53
This is a cherry-pick of https://android-review.googlesource.com/#/c/72973/ which is already in master, so do not merge.
Change-Id: Ic8911d3131e033747cfdabe59ac2fea1e90bb4a0
Do this both on input from apps (giving error) and between wifi and
ConnectivityService (ignoring bad data). This means removing all
addresses beyond the first and all routes but the first default and
the implied direct-connect routes.
We do this because the user can't monitor the others (no UI), their
support wasn't intended, they allow redirection of all traffic
without user knowledge and they allow circumvention of legacy VPNs.
This should not move forward from JB as it breaks IPv6 and K has
a more resilient VPN.
Bug:12663469
Change-Id: I0d92db7efc30a1bb3e5b8c6e5595bdb9793a16f2
Conflicts:
core/java/android/net/LinkProperties.java
services/java/com/android/server/WifiService.java
wifi/java/android/net/wifi/WifiStateMachine.java
The dreams manager also manages dozing. It has a minimal footprint
so there is no real reason to disable the component (it just makes
debugging more difficult).
Improved the documentation of the config_dreamsSupported resource
to clarify exactly what it controls.
Bug: 12494706
Change-Id: I78244846f7c1ddfd11bc1605af59b0db91337971
When the ActivityView is part of the home activity special checks
must be made. Things like don't move the home stack to the back
when the ActivityView activity is resumed.
Fixes bug 13119389.
Change-Id: I3a6040c9824dfd4b8ee97d58d131b14a519b470a
