These strings only ever end up in logcat (at best), so there's no
point having them translated. Also, rename the ErrorStrings class
and move it android.webkit where the last remaining caller lives.
(congrats webview people, this is now your mess to maintain.)
Change-Id: I04dae37c34191b26a69282970318c1b782af1edf
Move the code to the only point of use. Preparatory work for
decoupling apache-http from the frameworks.
Change-Id: Ieee54bb725cbac19d0c7513867635df6fbcf2b49
Also, move over DateFormat.getInstance(SHORT) instead of
LocaleData.shortDateFormat4 (which forces 4 digit years).
Based on an analysis of git history, there seems to be no
real motiviation for using 4 digit years.
If anyone in the platform complains loudly, we could look at
using a skeleton pattern instead of just replacing 'y' with 'yy'.
If third party apps are affected, we could add a targetSdkversion
based check and revert to the old behaviour for older targetSdks.
bug: 18388178
bug: 18322220
Change-Id: Ieab2b41691958a2e668d382c5a6b3d9aaf741ed2
The WeView provider implementation needs access to
these APIs to implement the WebView functionality.
BUG:18152150
Change-Id: I6b41c623b1e8a776dcee8977d0d17259cb4b34f1
(cherry picked from commits 94ef789f0c
and 53f2569487)
installd can then clear the ".booting" marker from the dalvik-cache
(owned by root). This marker is used to detect boot loops.
bug: 18280671
(cherry picked from commit 76a748e62f)
Change-Id: I2364c05837ac04d428b5a34ab1802964a11d2df4
Instead we install preloaded-classes as a standalone configuration file
/system/etc/preloaded-classes, so we can configure different file per product.
Bug: 18305157
Change-Id: I22f1a1dd44f90268d02532bf18405768523c0b1b
Changes the behavior of onKeyDown for DPAD_LEFT/RIGHT when in RTL
to move the progress in same direction as the DPAD key suggest.
Change-Id: I776a48711571884a10ef9315de78bf4ebffd6e4b
getHTMLColor is not aware of ARGB color format which is commonly used in
android xml files. This causes problem with coloring spans in resources.
Instead of above it should be changed to parseColor() with supported
formats: #RRGGBB #AARRGGBB
Bug: https://code.google.com/p/android/issues/detail?id=58192
Change-Id: I16bdf4c5c2a3b5e216b44e5c1955cac0104b3e12
With the recent introduction of AssetManager::appendPathToResTable,
overlay packages were not properly added to the AssetManager, and once
added, were not properly inserted into the ResTable.
Bug: 17765434
Change-Id: Ie21f227c654c98730f74a687d0e16ee2b80e747e
The close in finalize() is pointless, as finalize() will only be called
if there are no references to BluetoothA2dp. Until close() is called,
BluetoothManagerService will have a reference to BluetoothA2dp,
preventing garbage collection and finalize() to be called. This means
finalize() is not serving its purpose of cleaning up in cases close()
is not called, as finalize() is only called if close() has already
been called.
Actually calling close in finalize here means unregistering the already
unregistered mBluetoothStateChangeCallback which can lead to crashes
when pairing/unpairing BTH. A typical crash would look like:
*** FATAL EXCEPTION IN SYSTEM PROCESS: BluetoothManager
java.lang.NullPointerException
at android.os.RemoteCallbackList.unregister(RemoteCallbackList.java:143)
at com.android.server.BluetoothManagerService$BluetoothHandler.handleMessage(BluetoothManagerService.java:780)
at android.os.Handler.dispatchMessage(Handler.java:99)
Change-Id: Ib65962917ecbacf7900d7fe540057e6915f0532d
onRestoreInstanceState restores the old error, after layout has been
done. A new error may have been set before this is done, which thus
overwrites the new error.
This patch prevents the new error from being overwritten.
Change-Id: I8e7c91b5da27310fb6698e671d1f7d78ee268061
libcore now offers a wider variety of 12-/24-hour time formats,
so be more specific about which one we want here.
(cherry-pick of 85f60d3a03b5b5d9a0e8b8a138eb85a6b53a1eca.)
Bug: 10361358
Change-Id: I846ab7a6f84cd49e876ad21e9366aff1600e0530
On modern versions of Android running in AOT mode
FloatMath is slower than Math. Calls to Math.sqrt(),
etc. are replaced by intrinsics which can be as small
as a single CPU opcode.
When running in interpreted mode the new
implementation is unfortunately slower, but I'm
judging this acceptable and likely to be improved
over time. This change saves a small amount of native
code.
Example timings:
Mako AOSP AOT:
Method: Original / New / Direct call to Math
ceil: 596ns / 146.ns / 111ns
sqrt: 694ns / 56ns / 25ns
Mako AOSP interpreted:
Method: Original / New / Direct call to Math
ceil: 1900ns / 2307ns / 1485ns
sqrt: 1998ns / 2603ns / 1788ns
Other calls Mako AOT:
Method: Original / New
cos: 635ns / 270ns
exp: 566ns / 324ns
floor: 604ns / 150ns
hypot: 631ns / 232ns
pow: 936ns / 643ns
sin: 641ns / 299ns
The advice to use Math directly, in preference to
FloatMath, is still good. FloatMath will be deprecated
separately.
Bug: https://code.google.com/p/android/issues/detail?id=36199
Change-Id: If07fcbd78543d13bc6d75f9743f999860e8d58d7
