This adds the ability to use Application-Layer Protocol Negotiation
(ALPN) through the SSLCertificateSocketFactory. ALPN is essentially
like Next Protocol Negotiation (NPN) but negotiation is done in the
clear. This allows the use of other protocols on the same port (e.g.,
SPDY instead of HTTP on port 80).
Change-Id: Ie62926b455e252c4c98670bbbecc1eb5c6f13990
Amend DateFormat.getDateFormat to CLDR data from icu4c
instead of locale specific resource entries which are incorrect
for several locales.
No CTS tests are added as they require changing the locale which
is not currently possible.
Bug: https://code.google.com/p/android/issues/detail?id=56385
Change-Id: Ibd11c7fd9b595e19a3e2bf508e1585aa50067e03
Signed-off-by: howardb <android@howardb.com>
Before, we'd have something like 2006 4月12. After, we have 2006 4 12.
The alternative would require using custom NumberPicker.Formatter instances
for the year and day fields in these locales, and that seems significantly
more disruptive.
Bug: 8766552
Change-Id: I568578aae2f80f2acfc53cd277ef3beae6743472
mAttachInfo may be set to null by other threads while running
getHandler().
This fix assigns mAttachInfo to a local variable. Checking null pointer
and getting a member variable are executed through the local variable.
This local variable is constant. So NullPointerException doesn't occur
even if mAttachInfo is set to null while running getHandler().
Change-Id: I4013dfb7951bd864628868ed58f8c4f5b7cbd1d3
There was a deadlock in destroy process.
Investigation showed that WebViewCoreThread is waiting some
callbacks but in this case WebViewCoreThread can not resume
itself not to call notify method.
Flow:
1. CallbackProxy.sendMessageToUiThreadSync
2. WebViewClassic.destroy()
3. CallbackProxy.blockMessages()
4. CallbackProxy.handleMessage is called via MainThread
5. The WebViewCoreThread deadlock is occured.
The cases we have to call notify method are followings.
OVERRIDE_URL
CREATE_WINDOW
SAVE_PASSWORD
NOTIFY
OPEN_FILE_CHOOSER
JS_ALERT
JS_CONFIRM
JS_PROMPT
JS_UNLOAD
JS_TIMEOUT
Change-Id: I9d95ae500bf6338d77b32b5fa15de7cff5720d0f
When accessing an invalid entry of the list, an IndexOutOfBounds exception is thrown, not an ArrayIndexOutOfBounds exception.
Change-Id: I3cf59faab004fa6391d84f30f280e0c9bd92dc44
Signed-off-by: Taylor H. Perkins <taylorhp@gmail.com>
DatePicker always effectively uses yyyy MMM dd, so we need to ask
icu4c what order those should appear in for the user's locale. The
existing DateFormat code was an approximation that worked for en_US
but not for all languages (fa being one example).
Bug: 7207103
Change-Id: I7b12568dbc02522ebad6e1db5f8426109cd6f7ce
In some situations the collection.sort() algoritm fails in compareTo()
with a: java.lang.IllegalArgumentException: Comparison method violates
its general contract!, due to a more strict validation of the compare
contract.
This strict validation was introduced in java 1.7.
See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6804124
This fix should prevent the sorting from crashing.
Change-Id: I64230e7f62f83c99d7a6274964bb2988ae843826
In order to let apps use keystore more productively, make the blob
encryption optional. As more hardware-assisted keystores (i.e., hardware
that has a Keymaster HAL) come around, encrypting blobs start to make
less sense since the thing it's encrypting is usually a token and not
any raw key material.
(cherry picked from commit a3788b00bb)
Bug: 8122243
Change-Id: Ifc1c64743651b23a4eace208ade0176af47ea989
Marking a text on the web page and then press copy works,
but trying to mark the same text again does not work.
The reason for this is that the selection never gets
cleared in webkit.
The fix, calling cleaSelection in the onDestroyActionMode.
Also added clearSelection when getting an
onConfigurationChange.
Change-Id: I59b384cb5441b6a3a05007ea7e77f9699889a87c
When locale is non-English like korean, chinese, etc.,
month displayed string is started with number.
So, It's better to use Number IME for month selection.
Change-Id: If0444d62679b1f31d98fdedd2f06c2d445cade2a
It's not correct to state requestCode is 'currently not used'. It can be
used to differentiate multiple PendingIntents since a number of Android
versions now. Also, the introduction block of the PendingIntent
documentation explicitly states this as a possible use:
"If you truly need multiple distinct PendingIntent objects active at the same
time [...], then you will need to ensure there is something that is different
about them to associate them with different PendingIntents. This may be
any of the Intent attributes considered by Intent.filterEquals, or
different request code integers supplied [...]"
So fix the documentation inconsistency to make the possible use
immediately clear.
Change-Id: Ia65d7a5ab12c2c3ee1aa1c5107e5ea8fd937b765
