| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
Ref: CYNGNOS-453
Change-Id: I5aaf315f0d2b7b039cacb5de135501cea4f7cf0c
Signed-off-by: Roman Birg <roman@cyngn.com>
|
|\
| |
| |
| |
| | |
* commit '3bb833819dba8d530620ad6d43dc53c3fd54763b':
Add a ZoneInfoDB.hasTimeZone API.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Allows us to query the DB without having to clone an object or
an entire strings array.
bug: 19106773
bug: 19987403
Change-Id: I66d466e414972b02a75bcfe68263e74de8b9a768
|
|\ \
| |/
|/|
| |
| |
| |
| | |
StringFactory."
* commit '39f72b16952fbe4aff5c2e080ce9f7f6dbb1b93d':
Removed offset and value from String and added StringFactory.
|
| |
| |
| |
| | |
Change-Id: I55314ceb906d0bf7e78545dcd9bc3489a5baf03f
|
|\ \
| |/
| |
| |
| | |
* commit 'ccb61deb8f478f91404b75cbe19cb7b9cbcb4f76':
Move java.nio.Charsets to libcore.util.
|
| |
| |
| |
| |
| |
| |
| |
| | |
This isn't public API, and isn't related to NIO. It's only ever
used by java.lang.String.
bug: 10898787
Change-Id: I4e194406746b88ba7268c2553e467e7e05400b40
|
|\ \
| |/
| |
| |
| |
| |
| | |
for ICU and libcore"
* commit '8426170b2440ce9d9857f8b63e5de5f77d7ee393':
Changes to enable timezone data overrides for ICU and libcore
|
| |\ |
|
| | |
| | |
| | |
| | |
| | | |
Bug: 19941636
Change-Id: Id587be99f645978c2e1067c9f8eef26d6d63ec27
|
|/ /
| |
| |
| |
| |
| |
| |
| | |
For backwards compatibility with the apache code this is replacing.
Several callers compare encoded strings for byte equality.
bug: 19731588
Change-Id: I2e96abcabd69ba6d48d341eafe1f8075fff880ee
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are several open questions that I hope to resolve in future
changes :
- Our heuristics for detecting whether a zip outputstream should
switch over to zip64 or not are imprecise.
- Also, given that we now officially support zip64, we have to assume
new entries whose size is unknown need the zip64 header / footer.
This will make output files slightly larger and less compatible with
older tools. If we don't do this, we'll have to go back and rewrite &
compact parts of the stream we'd already flushed, which isn't always
possible. The other option is to assume zip32 for streams of unknown
length and throw if more than 4G of data is written to them.
Change-Id: Ibb4a97b5f83fd3ab850d7c407ecfda663968a6b9
|
|
|
|
|
|
|
| |
Tiny change after commit 2237a9d0ea59928f8852c9f599bdd9a6930e727d
to compare a long with a long.
Change-Id: Iaba2d7246295f3f23c760fe72195136208a95933
|
|
|
|
|
|
|
|
|
|
|
| |
The least messy fix is to change mTransitions to long[] despite
the underlying tzdata being ints. This leads to neater code than
comparing the unix time (as a long) against the first and last
element of the transitions array.
bug: 18839557
Change-Id: Ife562749e8b2160f664d566a0a2aae14a0aea36e
|
|
|
|
|
|
|
|
|
|
|
|
| |
GregorianCalendar has a minimum-cost constructor that is not available
on the host. This change wraps the call to that constructor in a static
method that LayoutLib can replace.
Bug: http://b.android.com/79160
(cherry picked from commit 8edeef21e47c2fd104fc6e1c8b26fc913945e0b9)
Change-Id: I6cfdf2e4401dfb02efca3a41d61cd474b58da850
|
|
|
|
|
|
|
|
|
| |
Frameworks callers either roll their own or use an internal apache
class. Given that apache is going away, we need to provide them with
an alternative.
bug: 18027885
Change-Id: Iec01cba9f3d2027828457c0b450eac0dd08fcaf6
|
|
|
|
|
|
|
| |
(cherry picked from b0edf66dfcb330e64ae50b8430a0849d4a819774.)
Bug: 18139284
Change-Id: I87d52e4f5bf18692a47c762fb4155ba68beffae2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently implemented is "are there any offset transitions
in the future?".
This is wrong: Transitions may occur in the future because
of DST, but can also occur for other reasons (e.g. if the
raw offset for a zone changes).
We should be implementing: Is the currently active transition,
or any transition in the future, one that has
isDst == true.
This was causing a test failure in
libcore.java.util.TimeZoneTest#testDisplayNames
for Asia/Novokuznetsk and Europe/Simferopol for
tzdata2014g. This is because they have a transition entry
for October 26, 2014 (i.e. in the future).
For each, the existance of the transition entry is not
due to an offset change at all:
For Asia/Novokuznetsk it is because the abbreviation
for the zone changes on that date (information we don't
curently use).
For Europe/Simferopol it is because the offset from
UTC changes on that date (but there is no actual DST
transtion).
Bug: 17377276
(cherry-picked from commit d42af6ed0fec3cfca52912b0d8b3b459e72be4b4)
Change-Id: I148503280b8dee653bac32eec3aa58d232102628
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was broken by the removal of the pre-computed raw offsets from
the tzdata file. I think that's still the direction we want to go (with
us hopefully using more of icu4j at some point, and eventually relying
solely on the icu time zone data), so this patch adds code to lazily
evaluate all the offsets by instantiating all the time zones.
(cherry-pick of 065d7764ac1dfe74ee94d17ca6c810de37b57d3e.)
Bug: 16947622
Change-Id: I6d1dfe5ee6c99338f9807c3af5b6f04539c256c3
|
|\ |
|
| |
| |
| |
| | |
Change-Id: I70a591093557ce3dd0471bcc7e888d630c80bb88
|
| |
| |
| |
| |
| | |
Bug: 15765976
Change-Id: Ic743168a54ff96e5403a9c73c27eeb7d482a01dc
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This reverts commit 01b6a878d10ee68db87c3d85d137e81a5257a78a.
Contains a fix for when the timezone ID is not found.
This includes a new test.
Change-Id: I2e5e669782ea6caf4e97153ed6b63ca6ee4ef50d
|
| |
| |
| |
| |
| |
| | |
This reverts commit a6e8689807f5a8bb9470ce7c26a47455d2d0608d.
Change-Id: I17a0262d169db3418f2f8888195381f778975dc4
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This mirrors the single-item cache in localtime.c.
This is in preparation for an upcoming change to migrate
android.format.text.Time over to Java. It will be making
use of the Java ZoneInfo instead of the native
equivalent.
The Java cache has a size of 1 like the bionic one,
though this can easily be increased.
Given the default TimeZone / ZoneInfo was always
pinned, in many cases the memory usage will not
go up noticeably. In scenarios where applications load
timezones besides the default a cache size of 1 potentially
increases pinned memory usage by one ZoneInfo plus
the overhead of the prototype object held by the cache
(which is never returned to callers).
An example ZoneInfo is "Europe/London", which has ~190
transitions (1 int + 1 byte) and ~6 types (1 int + 1 byte).
Overhead of other fields is ~ 13 bytes, plus the ID string.
190 * (4 + 1) + 6 * (4 + 1) + 13 = 993 bytes.
The prototypes held by the cache share the majority of their
memory with their clones returned from
ZoneInfo.makeTimeZone() and so the overhead of introducing
the cache itself should be in the order of a few tens of
bytes at most.
In future we may want to increase the cache size to 2 in
order to support apps that compare / switch timezones to
increase the odds of the default remaining in the cache.
Sizes above 2 look increasingly specialist.
Change-Id: I0b7daa8ad5d334c8d421dfaa6e0421d3c181a915
|
|
|
|
|
|
| |
This reverts commit 510b95208a6ec9b92cd9debe954c338a8ca8cf88.
Change-Id: Ifaabadfb43b61bf72bf436451612ebf629a70648
|
|
|
|
|
|
|
|
| |
I need to change a dependency in an internal-only class, but some
genius took our building off the net at 17:30 local time. I'll
remove this and fix the internal tree tomorrow.
Change-Id: I0f9a3ae282e1d043d818f028cdcb80854f943151
|
|
|
|
| |
Change-Id: Ie700aa16d91fba53fc5eb2555829cb74d84b12ad
|
|
|
|
| |
Change-Id: Ib229283546e47f31107331e2323f112ef2a0dd6b
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug: 10244719.
Also, make wider use of empty arrays.
Also, use named inner classes to aid profiling.
Remove caching as the empty result will be fast.
Porting the ART changes to DVM, to avoid the caching, results in bringing
in a bunch of other ART clean-up.
TODO, avoid modified-UTF8 to String conversions by Dex.
Change-Id: I051b6e34b5a4e7a7f1383461a799755947a5ba36
Conflicts:
libdvm/src/main/java/java/lang/Class.java
|
|
|
|
|
| |
Bug: 3484927
Change-Id: I5820267491b850b8fcc696fa48962710de123009
|
|
|
|
| |
Change-Id: I05aff6c07e9baca679b8b7759f4f0108067d06e6
|
|
|
|
|
|
|
|
|
|
| |
We need to fall back to the next choice on error. Rewrite the code
to be testable and add some tests. Add an internal GMT-only
fallback in case all our sources of tzdata are bad. Also make
time zone detection on the host more useful.
Bug: 8373554
Change-Id: I9f91b844a61f07f34b268535e6d24aa0c301bf8d
|
|
|
|
|
| |
Bug: 8391426
Change-Id: I7b1335a8d8e0c804d68c85b18b1c4891ec269c1d
|
|
|
|
|
| |
Bug: 7012465
Change-Id: I2ac580094928806abcf7c6f5f0e6ee950a954135
|
|
|
|
|
| |
Bug: 7012465
Change-Id: Ia452f9c4482d0a75073e6a174f38114525984f15
|
|
|
|
|
|
|
|
|
| |
The code that generates the single big file from the directory of
zoneinfo files needs to be able to get the raw offset for each zone,
so we can implement TimeZone.getAvailableIDs(int) cheaply.
Bug: 7012465
Change-Id: Icc8355c086dd8e62589c2930fb7f892feea5a217
|
|
|
|
|
| |
Bug: 7012465
Change-Id: I5ce1a372755e31f8882fbfc2ea2b582fec1858b3
|
|
|
|
|
|
|
|
|
|
|
|
| |
Dalvik Explorer can now do a better job of helping examine transition data,
and regular developers don't need to see it. For America/Los_Angeles, for
example, toString used to output 186 lines. Now it just returns:
libcore.util.ZoneInfo[id="America/Los_Angeles",mRawOffset=-28800000,mEarliestRawOffset=-28800000,mUseDst=true,mDstSavings=3600000,transitions=185]
Also fix an incorrect comment from the TimeZone documentation.
Change-Id: I5748845a7b4f911e99a0e1c2e1a0786742288518
|
|
|
|
| |
Change-Id: I207a3226470557ac26caba165ef35f5df6859273
|
|
|
|
|
|
|
|
|
| |
Semi-automated replacement of empty and non-conforming
NullPointerException reason messages.
(cherry-pick of 86acc043d3334651ee26c65467d78d6cefedd397.)
Change-Id: I6d893979f5c20a50e841e32af9fd7b2d8bc9d54d
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Australia/Lord_Howe has a half hour difference between standard and daylight
time, rather than the usual hour. Our ZoneInfo implementation ignored this.
Fix that oversight, make SimpleDateFormat actually use this information, and
prevent TimeZone.getTimeZone("GMT") and TimeZone.getTimeZone("UTC") from
being quite as expensive as they accidentally were.
Longer term I think we should probably remove all uses of getDSTSavings from
libcore in favor of TimeZone.getOffset, but this is probably a useful step
forwards anyway. It fixes Australia/Lord_Howe in the meantime and it means
that anyone else who's using getDSTSavings won't be bitten (even if they too
really ought to be using TimeZone.getOffset).
Bug: 4723412
Bug: http://code.google.com/p/android/issues/detail?id=24684
Change-Id: I5d50afecbe1453157e9c8f0b88305a258a3ba2e0
|
|
|
|
|
| |
Change-Id: Ia4aaf5f0ef5a2f5f7e6ec3e8b4c4e300c9e1b2ee
http://b/4144865
|
|
|
|
|
| |
Bug: 4486011
Change-Id: I1877ce593d441653f75ab14884aa2d85f52652ad
|
|
|
|
|
| |
Change-Id: I5604ad7f96c824e4df78a5ebd78845d012aedc13
http://b/3484927
|
|
|
|
|
|
|
|
|
|
|
| |
This patch marks the end of OSFileSystem.
Having to support a Java "long*" for sendfile(2) gave me an opportunity to go
back and improve my ioctl(2) to use a corresponding "int*" equivalent, instead
of its previous special-case hack.
Bug: 3107501
Change-Id: I9fde4777700552263fab4fe9aeb556174163e3dc
|
|
|
|
|
| |
Change-Id: I0ceb442801160827909ff9ab3e52771754072bda
http://b/4087759
|
|
|
|
|
| |
Change-Id: I74e056120b65578104ca4596401d0de0b9747114
http://b/4087759
|
|
|
|
|
| |
Bug: 3107501
Change-Id: I6a7c4147ec27bab9ded280476bad1157ce03fab8
|
|
|
|
| |
Change-Id: I67bb9f1c71c774e04698a3e489bd48e9b27b2b64
|