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)
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
For these font families, text was always rendered as italic. This
changeset fixes the issue.
Bug: http://b.android.com/57221
Change-Id: Ic8a299bd1e555f5bb914cd3d2fe72917ec7f471a
(cherry picked from commit e327212adde1136807bbdf052e8cc3861f8a6aba)
If a style doesn't specify text style (normal/bold/italic/bold-italic)
then default to normal instead of throwing an error.
Bug: http://b.android.com/61358
Change-Id: I0138c73807a5ff6e4d938a99ece3044333110aa1
(cherry picked from commit 0acfb16dcd95468fe032204f54618e86becfd1eb)
When switching USB modes there are often spurious connect and disconnect events
that occur before reenumeration is complete. There is currently a 1000ms timer
to "debounce" the disconnect events. But with some USB accessories, this timeout
is not long enough, which results in an endless cycle of attempts to enter
USB accessory mode when the phone is connected.
To fix this, we now wait up to 10 seconds for the host to successfully configure
the device when entering USB accessory mode before giving up.
This is separate from the existing debounce timer, so the behavior of the
USB state change broadcasts are not affected.
Bug: 12877769
Change-Id: I7aa61f8a618546d749a7ddfc97bf103029a73d03
1. Fix a bug where baseline of the run was modified while rendering
resulting in crooked text in some cases.
2. Use GlyphVector.getLogicalBounds() for text measurement which is more
accurate than getVisualBounds().
3. This change also optimizes text rendering by not computing the advances
for individual glyphs when not needed.
Change-Id: I66792c4d8f50eaf29afa70bccca1e6c812a3fa28
The nine patches were not drawn correctly if they were not positioned at
the top left corner of the canvas.
Bug: http://b.android.com/29959
Change-Id: Icfed522ea07322a3ee9f3955067d3da26c4b0b5b
