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
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
