This may mean that secondary networks have bad network settings,
but currently default settings are overriden by secondary nets
which seems worse.
bug:13211589
Change-Id: I08d56e618208781bf6b21a88663c2b8503a4f226
Remove private WM flag (used only by the volume panel) to force
the clearable system UI flags clear.
Instead, always lay out the volume panel as if the bars are visible,
as we do for system dialogs - and don't clear the flags.
Reverts part of I25f29af5b6518aba695b64a75977ae240b742118
Bug:11986621
Change-Id: I842729d729d2a6eb2a687d0b930ddb160c6a1b57
User 0 owns the window (system_server) but should be allowed
to display on a user's behalf.
Use the corresponding private flag for this system window, since
we cannot classify it by type (TYPE_TOAST) in policy.
Bug:12015090
Change-Id: I33aedb4624288415a5e1ae937676b693024546a9
Maintain fallback to OPAQUE mode on low-end devices in place of the
translucent modes.
Bug: 12546110
Change-Id: Ia3582c305cb09aadd56c6aa58b039a174675c79a
We need to specify "PBKDF2WithHmacSHA1And8bit" now in order to get precisely
the same output as was previously generated with "PBKDF2WithHmacSHA1". We
also now try both when it's ambiguous which was used to generate the archive
checksums.
Bug 12494407
Cherry-pick from master.
Change-Id: I2d6081dd62f50f7d493045150b327ed120de7abd
The ACTION_EXTERNAL_APPLICATIONS_UNAVAILABLE broadcast now uses the
EXTRA_REPLACING intent extra when it is sent as part of an upgrade operation
on a forward-locked application. Update PackageMonitor to recognize this
new information and express it appropriately to the observer.
Bug 11988313
Cherry-pick from master.
Change-Id: Iecea1876ffc918f23f9fa5845f1f89ed8d740dd5
Follow up to Change-Id: Ibc2496d5cef97b4685e001086f712fcaac231024 - this
method did not exist in klp-dev branch.
Change-Id: Ie64dd3b2357e0abefb4c7d3492f02d23d347f89f
(cherry picked from commit b212b9f2ba709273b3d46a1ef3b091eb2292c917)
Cherry pick to klp-dev as part of Bug: 13246014
This is going to be used by pagecycler tests.
See: b/10629847
Change-Id: Ie3fda214e7808429d7ed63734ab301525f58513f
(cherry pick of 244267500254daff8745f8c0fae3edcac735873f)
Cherry pick to klp-dev as part of Bug: 13246014
Conflicts:
core/java/android/webkit/WebViewClassic.java
core/java/android/webkit/WebViewFactoryProvider.java
(cherry picked from commit 54daaf1cffddad6366fac2ccfceb1e042dd8e90e)
Change-Id: I8471ee5cfaac2ff72704c2391a1961f441aaa1e6
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 5bab9daf3cf66f4de19f8757e386030e8bef23ce
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 5bab9daf3cf66f4de19f8757e386030e8bef23ce)
Reverts commits 4567e40eb04589d211af82f2dcb16cb3955c605e and
a977707d6e7006d11cfde045f187e777b31b9e04, which added special case fallbacks
for game controllers in the Japanese locale.
Bug: 12923922
Change-Id: I229126e589e11fb5de86772ef9c59d09723af941
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
