As part of moving DeviceConfig.java to packages/modules/ConfigInfrastructure.
Need to move activity thread dependency to setting.config as the new
module will not have access to hidden apis (ActivityThread).
Test: m
Bug: 258220607
Change-Id: Ib7b20caaec128d64908349918ec7bce9a53cc2e6
BinaryTransparencyService:
- change default binary measurement method from SHA256 digest to
APK content digest. This allows for more performant measurements.
- got rid of in-memory caches of digest results because:
a) larger scope: more binaries will be covered (in the magnitude
of hundreds);
b) the digest length using APK content digest might be longer than
256 bits: e.g. CHUNKED_SHA512 which is 512 bits;
c) the computation of these new digests are not as computationally
intensive that it causes noticible lags even when commands are
invoked repeatedly in adb shell.
- changed scheduled job to be scheduled periodically (once in a 24
hour period) instead of a one-off job.
- make use of method calls to BackgroundInstallControlService (BICS)
to obtain list of newly installed mobile bundled apps (MBAs).
BinaryTransparencyServiceTest:
- modified the return type for `getApexInfo` to receive a List instead
of Map.
Bug: 245944666
Test: atest BinaryTransparencyServiceTest.
Also, adb shell cmd jobscheduler run android <job-id>.
<job-id> can be found in debug printouts with TransparencyService
tag.
Change-Id: Ie305e71c514f4fb65b9e640301093ec83f01f718
This keeps the broadcast ANR message consistent with the old broadcast
queue, and fixes trace analysis pipelines that consume messages in
this format. This unstructured format is brittle but should keeps things
working, pending a longer term fix to with structured (proto) format.
This CL also adds tests for TimeoutRecord to validate ANR timeout
records.
Test: m
Bug: 254452238
Change-Id: Ifd0fb8d4a1d0add3e762b8327defb3f25d5aa0c2
When a process becomes cached and holds file locks blocking other
processes, check whether those blocked processes are also in cached
mode. If they are also cached, freeze the current process. Otherwise,
Skip the current process to avoid deadlock.
Bug: 245994713
Bug: 253913470
Test: atest ProcLocksReaderTest
Test: verify apps with deadlock can be frozen
Change-Id: I8635bf877bbe4404cc66955f1946444265680246
This commit is part of a large scale change to fix errorprone
errors that have been downgraded to warnings in the android
source tree, so that they can be promoted to errors again.
The full list of changes include the following, but not all
will be present in any one individual commit:
BadAnnotationImplementation
BadShiftAmount
BanJNDI
BoxedPrimitiveEquality
ComparableType
ComplexBooleanConstant
CollectionToArraySafeParameter
ConditionalExpressionNumericPromotion
DangerousLiteralNull
DoubleBraceInitialization
DurationFrom
DurationTemporalUnit
EmptyTopLevelDeclaration
EqualsNull
EqualsReference
FormatString
FromTemporalAccessor
GetClassOnAnnotation
GetClassOnClass
HashtableContains
IdentityBinaryExpression
IdentityHashMapBoxing
InstantTemporalUnit
InvalidTimeZoneID
InvalidZoneId
IsInstanceIncompatibleType
JUnitParameterMethodNotFound
LockOnBoxedPrimitive
MathRoundIntLong
MislabeledAndroidString
MisusedDayOfYear
MissingSuperCall
MisusedWeekYear
ModifyingCollectionWithItself
NoCanIgnoreReturnValueOnClasses
NonRuntimeAnnotation
NullableOnContainingClass
NullTernary
OverridesJavaxInjectableMethod
ParcelableCreator
PeriodFrom
PreconditionsInvalidPlaceholder
ProtoBuilderReturnValueIgnored
ProtoFieldNullComparison
RandomModInteger
RectIntersectReturnValueIgnored
ReturnValueIgnored
SelfAssignment
SelfComparison
SelfEquals
SizeGreaterThanOrEqualsZero
StringBuilderInitWithChar
TreeToString
TryFailThrowable
UnnecessaryCheckNotNull
UnusedCollectionModifiedInPlace
XorPower
See https://errorprone.info/bugpatterns for more
information on the checks.
Bug: 253827323
Test: m RUN_ERROR_PRONE=true javac-check
Change-Id: I8446f9076a45ebf7e7ffa06cb0d4ddb1001b6c00
onMeasure was being called 246 times in 26 ms, and having all those traces was not helping much and causing a few millis of latency.
Bug: 258930580
Test: Recorded a perfetto trace and inspected it manually
Change-Id: I672b785a57fe6c6d78b6a89e68fa57735c225bc7
Allows WM Shell to indicate the start/end of drag resizing, which
core can use as a signal to reuse a single (larger) surface size
for the entire drag resize operation to avoid continuous buffer
allocations after each size change.
Bug: 249808500
Test: drag resize a freeform window, verify WindowLayout requests
a fullscreen sized surface; atest TaskPositionerTest
Change-Id: I27e2b44270d7ea4f701fa8037f93b20dc691284b
On upgrade from Android 13 or earlier, LockSettingsService is creating a
synthetic password (SP) for all users that didn't have one before, and
re-encrypting the user's CE key with the SP. Currently this happens at
PHASE_BOOT_COMPLETED, since Weaver is not yet guaranteed to be available
at the previous phase, PHASE_THIRD_PARTY_APPS_CAN_START.
An issue with using PHASE_BOOT_COMPLETED is that during an upgrade,
PHASE_BOOT_COMPLETED happens after the userdata filesystem checkpoint
has already been committed. Therefore, if a problem occurs with the
migration to SP, the changes won't be rolled back and the device will be
left in a broken state, recoverable only via a factory reset.
Important migrations like this should happen before the checkpoint is
committed. Therefore, replace the use of PHASE_BOOT_COMPLETED with a
direct call into LockSettingsService in an appropriate place, similar to
the existing LockSettingsService.systemReady() call.
I also considered creating a PHASE_THIRD_PARTY_APPS_STARTED boot phase.
However, any new boot phase would become part of the services API
(services/api/current.txt), which is more than I'd like to do here.
Test: Made an intentionally broken build with
LockSettingsService.onThirdPartyAppsStarted() changed to throw a
RuntimeException at the end, crashing system_server. Tested an
OTA from tm-qpr2-release to that build, on a device that didn't
have a lockscreen credential set on user 0 (so that user 0 was
migrated to SP-based credentials just before the crash). The OTA
failed as expected and successfully rolled back to the original
build, with user 0's data still accessible (this was not possible
before this change).
Bug: 232452368
Change-Id: I77d30f9be57de7b7c4818680732331549ecb73c8
