android.util is the only package shared between libcore and
framework, with only the Mutable* classes living in libcore.
This CL topic moves most of these classes to framework.
After this CL topic, only MutableInt and MutableLong remain
in libcore. This prevents future libcore dependencies on
android.util; it is a first step towards removing the package
overlap between libcore and framework.
Test: Treehugger
Bug: 67901714
Change-Id: Id466181cb0db747da17f38ddb0b99c3e522add16
This is a pure refactoring with no a behavior change other than
that these calls now go through android.system.Os, which immediately
delegates to Libcore.os.
This is a first step towards separating framework (via
android.system.Os) vs. libcore (via Libcore.os) clients of these
low level APIs. Separating these is a prerequisite towards moving
the API parts of android.system into framework, and moving the
rest into a different package in libcore.
Test: Treehugger
Bug: 67901714
Change-Id: Ifd8349ec5416e5693f40dba48fdf2bef651b7d81
Merged-In: Ifd8349ec5416e5693f40dba48fdf2bef651b7d81
To avoid issues with late initialization, let the holder be
initialized in the zygote.
(cherry picked from commit 61a3e8c23a)
Bug: 65927416
Test: m
Merged-In: I6f454df46d4c64d295e1f2510793d5087b74fb74
Change-Id: I6f454df46d4c64d295e1f2510793d5087b74fb74
If the AtomicFile does the rename and fails when writing the
original, make sure we can at least use the backup on reboot.
Bug: 63753300
Test: Stop shell, move settings_global.xml to backup, start shell.
Change-Id: I2049b48af05161bb2c68717a71c1700a95150a6c
Previously, the server side would omit reporting new configurations
during resize and relayout if the current configuration matched the
last reported. However, if the last reported came through a resize,
the client side handling would be enqueued as a Handler message. This
leads to the possibility of the client getting a new window frame but
not a new configuration where this is synchronously handled, such as
ViewRootImpl::performTraversals.
To address this issue, we now always send the current configuration
from the server to the client. The client then identifies changes
against its own record of last reported configuration and updates as
appropriate.
This changelist also adds a call to force window relayout during
updateConfiguration, as it's possible this is called after
performTraversals is called or resize is handled, leading to a stale
window frame.
Bug: 24671393
Test: go/wm-smoke
Test: Open Camera while rotating phone to landscape. Added
temporary logs to detect inconsistencies between measurements
and reported rotation on draw.
Change-Id: I0d5143dfe80400f6a43ce710750f9fc9d4b93f74
time_zones_by_country.xml has been replaced by a file that can
be updated outside of an OTA and can be accessed via
libcore.util.TimeZoneFinder. This means parsing code has been
removed from this class and replaced by calls to libcore code.
libcore code uses ICU so this class adapts to
java.util.TimeZone for published public APIs as well as other
knock-ons to reduce impact of this change in telephony code.
All use of classes called TimeZone are fully-qualified to
reduce confusion.
Several public-but-hidden methods have been removed. These
can be returned if there are any important apps relying on
them.
Bug: 25338903
Test: Ran CtsUtilTestCases
Change-Id: I699b4e7420e8d7e61ee68ec96552ab3144c9bab2
Only happens if you're put()ing and clear()ing the map from
different threads, and Dianne told you not to do that.
In addition to avoiding the cache poisoning that results
from concurrent access, ArrayMap now attempts to throw
ConcurrentModificationException if clear() or
ensureCapacity() or put() notices you've modified the map
elsewhere.
Bug: 32994281
Test: runtest -x frameworks/base/core/tests/coretests/src/android/util/ArrayMapTest.java
runtest -x cts/tests/tests/util/src/android/util/cts/ArrayMapTest.java
Change-Id: Ia75970aa9e2b2b65692179f51243584b9773797f
The Log.setWtfHandler() provides a way to override
the default TerribleFailureHandler, so that we can
test that a piece of code reports as terrible
failure as expected.
Unfortunately, we can't actual use setWtfHandler()
at the moment. The problem is as follows:
1. The Log.setWtfHandler() method requires a
Log.TerribleFailureHandler instance.
2. The Log.TerribleFailureHandler interface requires
subclasses to implement a onTerribleFailure()
method. The method requires a Log.TerribleFailure
argument.
3. Log.TerribleFailure is a private inner class.
Given the above, classes outside of Log can't create
an appropriate argument to pass to Log.setWtfHandler().
To resolve this, we update the visibility of
Log.TerribleFailure to be the same as that of
Log.setWtfHandler(), and Log.TerribleFailureHandler.
Test: m -j32
Bug: 37425059
Change-Id: Ie646b931869582398d61495e367e0d36e767a3e3
Clean-up before actual fix for b/36897968 that makes the code easier to
follow.
Test: Existing tests pass
Bug: 36897968
Change-Id: I3039548929440f922dc69d7f130169a3d60b1eef
* changes:
Fix broken CTS tests.
Draw a default focus highlight if needed.
Add a public API defaultFocusHighlightEnabled.
Detect unhandled keyboard focused state.
