Introduce a constant StrictJarManifest.ATTRIBUTE_NAME_NAME so that
callers (StrictJarManifest{,Reader}) don't need to rely on
Attributes.Name.NAME which was added via an Android patch.
Bug: 35910877
Test: Treehugger
Change-Id: I292fbefc6c5561609dcd8281d1e2a931a1ffa5b2
It makes sense to hide the details of the parser implementation
(and other similar objects) in libcore so it could be changed.
This change removes the "ExpatPerformanceTest" which appears not to have
been maintained and was comparing KxmlParser with itself. It is assumed
that android.util.Xml used to return the expat parser.
Test: build
Bug: 111055375
Merged-In: Ibad247323ba90cd949aecb2bd92f2f73306a4327
Change-Id: Ibad247323ba90cd949aecb2bd92f2f73306a4327
Track changes in libcore to remove a constructor + lint
import order changes. Instead of the constructor a utility
method is introduced.
Test: Build / boot
Bug: 111055375
Merged-In: Id683a9d9d6e27d4c8df623dae189da9e74a6d410
Change-Id: Id683a9d9d6e27d4c8df623dae189da9e74a6d410
Half has a dependency on an internal sun.misc.FloatingDecimal
that can be replaced by an equivalent call on java.lang.Float
(which calls through to FloatingDecimal).
Any performance hit is worth it for a smaller API surface.
Bug: 111055375
Test: Build
Change-Id: Iecdf3aa9414922a77edbdc439b0c2b88033b3af8
The client code now "suggests" time updates
to the time detection service. The current implementation
of the time detection service will validate and set the
device system clock as needed. In future it will ignore
these suggestions if better information is available.
Responsibility for sending the
TelephonyIntents.ACTION_NETWORK_SET_TIME intent has
been moved to the time detection service until it can be
removed or replaced.
The telephony code is still responsible for basic rate
limiting but the majority of the decision logic has been
moved to the service.
There is an associated change in telephony code to switch to
using the server.
Bug: 78217059
Test: atest FrameworksServicesTests:com.android.server.timedetector
Test: atest FrameworksCoreTests:android.util.TimestampedValueTest
Change-Id: I4f7a10ac06b2d32da22689e1ddf309e0a2795f30
This is sufficient to wire up time detection from telephony
to the new service without breaking time detection.
This cherry-pick contains a small change: to use
SystemClock.elapsedRealtime() instead of the newer
SystemClock.elapsedRealtimeClock() with Clock.millis().
Bug: 78217059
Test: atest FrameworksServicesTests:com.android.server.timedetector
Test: atest FrameworksCoreTests:android.util.TimestampedValueTest
Merged-In: Id7175878dc22e5272c31f3e478af4b0e4183b62b
Change-Id: Id7175878dc22e5272c31f3e478af4b0e4183b62b
(cherry picked from commit 24836bfb15)
Permits syncing over a specific network instead of the default for
the process. This was causing an issue with Android Wear devices
paired with iOS where the default network is bluetooth
(see b/32663274).
This CL is in support of ag/3776564
Bug: 32663274
Test: adb shell am instrument -e class android.net.SntpClientTest -w \
com.android.frameworks.coretests/android.support.test.runner.AndroidJUnitRunner
(cherry-pick of pi-dev Ic9fc169cf75457810d4992121d85d7642e350b90)
Merged-In: I339c77063c72a9d76a5c4cb17052e20fb6e045a6
Merged-In: I8dfd1cad99c63efdc14c174c19f094a61cdfc44f
Change-Id: I44df66688292b144ec7dfcdd9ae5d82489f82774
To avoid future merge conflicts, a dummy WorkChain class must be
added temporarily. It goes along with the dummy StatsLog.java class.
Bug: 71607284
Test: none
Merged-In: Iff361eb98e079c7b2146c092dc27a3618a813c94
Change-Id: I66cf0c36c1842b99a5a4dd104fc5c06c0cfbe2b5
This is a dummy class that provides StatsLog.write methods and
appropriate constants to log atoms in aosp.
Test: build success on Marlin
Change-Id: I606bc8a96337ced842eb7a2bcba8c4969c9d4748
Add 440dpi as a supported screen density
Bug: 72424600
Test: run android.dpi.cts.ConfigurationTest#testScreenConfiguration and android.app.cts.ActivityManagerMemoryClassTest#testGetMemoryClass
Change-Id: I0dbf998ae02515a97f0d5668eeedc7098da4cca4
Signed-off-by: weijuncheng <weijuncheng@xiaomi.com>
Since http://r.android.com/565744 , these classes do not appear
in the signature of any other Android API. There are no plans to
make them part of any future API signatures.
They do not provide useful abstractions because:
- They lack encapsulation and functionality (value is nonfinal;
lack of equals/hashCode and toString).
- It's trivial for apps to implement similar types for their
internal use.
Only three of these eight classes (Mutable{Int,Long,Boolean}) are
used internally in Android; most of these usages could be written
better with named, more specific classes.
Therefore these classes do not pull their own weight on the API
surface of android.util.
This CL deprecates all eight classes in preparation for removing
them from the Android API surface at some point in the future, and
to allow the unused classes to be removed entirely.
Bug: 71546998
Test: Treehugger
(cherry picked from commit d57219411b)
Change-Id: Ib8736faa86d0ae5eec2c47a294f21adcf21d3dc4
Merged-In: I1cc1eb5ca9c36749bbb9a233d60036f6319bf2d3
No libcore dependencies on these classes remain, so they
can now move to framework which already has all of the
other classes from android.util.
After this CL topic, libcore and framework no longer have
any classes from the same package.
Bug: 67901714
Test: make droid
Test: Treehugger
(cherry picked from commit 232f1eb387)
Change-Id: I65871516b762d8a53ebe01697e4d92f94903bfd3
Merged-In: I65871516b762d8a53ebe01697e4d92f94903bfd3
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
To avoid issues with late initialization, let the holder be
initialized in the zygote.
Bug: 65927416
Test: m
Change-Id: I6f454df46d4c64d295e1f2510793d5087b74fb74
In several places we compute the sha256 of the app's signing certificate
(instant cookie storage, backup account permission grants, static shared
lib matching). It is possible that an app is singed with multiple certs
which unfortunately can appear in a random order. We were using only the
first certificate to compute the hash which may be problematic for apps
signed with multiple certs which are later reordered. If an app update's
certs are reordered for cookie storage the app would not be able to
access the cookie, for account grants the app would not get the grant,
and for shared libs the app would fail to install due to a missing lib.
Test: all cookie CTS tests pass
all static shared lib CTS tests pass
added test that cookie data not lost on sha256 computation change
added test that lib install works when specifying
multiple certs
bug:64270295
Change-Id: Ib6b55f25da735ff5c2762faf6e9b5888e749041d
Email auto linking used to accept either a single char or more than 2
chars in the local part. Updated the regular expression to accept 1 or
more chars.
Test: added test to cts.LinkifyTest
Test: bit -t CtsTextTestCases:android.text.util.cts.LinkifyTest
Test: bit -t FrameworksCoreTests:android.util.PatternsTest
Test: bit -t FrameworksCoreTests:android.text.util.LinkifyTest
Test: bit -t CtsWidgetTestCases:android.widget.cts.TextViewTest
Bug: 64467661
Change-Id: I4e28a344ff1bc50da353b9490eaaec99a751bffb
(cherry picked from commit e17c5b478e)
Renamed BootTimingsTraceLog to TimingsTraceLog. It is now used for
boot and shutdown logging.
Added measurements for main stages of shutdown in the system server:
ShutdownTiming: SendShutdownBroadcast took to complete: 734ms
ShutdownTiming: ShutdownActivityManager took to complete: 203ms
ShutdownTiming: ShutdownPackageManager took to complete: 17ms
ShutdownTiming: ShutdownBt took to complete: 533ms
ShutdownTiming: ShutdownRadio took to complete: 534ms
ShutdownTiming: ShutdownNfc took to complete: 1536ms
ShutdownTiming: ShutdownRadios took to complete: 1538ms
ShutdownTiming: ShutdownStorageManager took to complete: 906ms
ShutdownTiming: SystemServerShutdown took to complete: 3918ms
Bug: 64569080
Test: shutdown/reboot and check logs
Change-Id: I636c045852cd1ed6be1c58af6608f70e95756389
Devices routinely boot in a state where the RTC is wildly incorrect
in the past (2009, 1999, or even at Unix epoch zero). When we have
persistent jobs to be scheduled at boot, this presents a problem: when
should those jobs run, given that our idea of "now" is incorrect?
The previous implementation fell back to rescheduling these jobs
"from scratch" in this situation, as though they were newly-introduced,
but this turns out to have some emergent pathologies when the jobs
were intended to become runnable after long initial delays: the
rescheduling behavior could wind up starving jobs out entirely,
never running them regardless of how much real uptime the device
had, given the "wrong" pattern of reboots.
We now preserve the original nominal schedule, but recognize when we
have booted in a pathological situation, and correct the schedule for
these jobs when the system clock becomes sensible.
Bug 63817592
Test: JobScheduler test suite plus manual bogus-boot-time repro
Change-Id: Ia36fc5298b68db74e4e07e973b68e68e66206b43
Clean up SubscriptionPlan, add docs, and expose as public API.
Deprecate older constants in CarrierConfigManager, and point users
towards new API. (The goal of CarrierConfigManager is to express
key/value pairs that are identical for all users on a particular
carrier, not to configure details that vary between users.)
Since a CarrierService may itself not have access to the plan
details, allow them to "delegate" the capability to configure plans
to another package name.
Factor out new RecurrenceRule class which is used by both
NetworkPolicy and SubscriptionPlan internally. Polish it to support
arbitrary periods, and continue to test it through NPMST.
Bug: 63391323
Test: bit FrameworksCoreTests:android.util.RecurrenceRuleTest
Test: bit FrameworksServicesTests:com.android.server.NetworkPolicyManagerServiceTest
Exempt-From-Owner-Approval: Bug 63673347
Change-Id: I93fae4a43e58e9e4c32f8bf345a257dcd607f088
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
Telling kernel module uid_cputime to stop accounting time for uids
belonging to a stopped user. Upon user remove, removing uid states for
those uids.
Test: adb shell am instrument -e class \
com.android.internal.os.BatteryStatsUserLifecycleTests -w \
com.android.frameworks.coretests/android.support.test.runner.AndroidJUnitRunner
adb shell am instrument -e class android.util.SparseLongArrayTest -w \
com.android.frameworks.coretests/android.support.test.runner.AndroidJUnitRunner
Bug: 62390461
Change-Id: Ibe07778465e3d2c13679e4d88d32f7b92fa959d9
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
Apps with a normal UID are typically isolated enough to not require
socket tagging; we're mostly interested in tracking down internal
UIDs that have lots of code sharing the same UID.
Also fix up everyone doing manual string checks of Build.TYPE, since
we now have first-class fields for those.
Bug: 38126076
Test: builds, boots
Change-Id: I3a40348196bd8459289f2b9355d9783a07f1e7dd
Calendars are cloned once per format argument they're used for and cloning
a calendar is quite expensive. The line modified by this change used to
create dozens of objects, most of them pointlessly cloned.
Instead, we LocalDateTime, which is immutable and will be used directly.
Moreover, we can rely on its toString method which is specified to
format dates the same way we were doing in this class.
Test: manual
Change-Id: Ia2f6f5eb4f79252663c22b5a81d747c928771ee9
