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
Need to land this fix in tm-dev for it to show up in the published reference docs.
Bug: 237562620
Test: [go/atsd docs build]
Change-Id: I5f562b70d04bc86779190002a2640fb51dc00531
(cherry picked from commit 0547bffe400ecc877e22701d6bd7f6af33c29b4d)
The ArrayEquals, ArrayHashCode, ArrayToString, and
ArraysAsListPrimitiveArray errorprone findings were
demoted from errors to warnings. Fix existing
occurrences of them so they can be made errors again.
Bug: 242630963
Test: RUN_ERROR_PRONE=true m javac-check
Change-Id: Ia6f216cc36ad0a5758f39fd9b34962cd4adf9d8e
clipPath is already anti-aliased since Android S, so we do not
need to create extra bitmaps for this
Bug: 211896569
Bug: 238937089
Test: Updated tests / presubmit
Change-Id: I60ce42d91ca96babbde9faa4e5580b00f681de35
This adds tracing to ImageDecoder for image loads. When a drawable is
being loaded, it'll emit a short description of the resource and desired
loading sizes. This will make it significantly easier to find large,
slow bitmap loads when debugging regressions.
Bug: 235451049
Test: physically on a Raven device
Change-Id: I615342f1bd11d867e0bd33209507330848df8525
Before this CL, minimum dimensions of Activity wasn't respected,
that said, an Activity could be embedded in a TaskFragment of which
bounds are smaller its minimum dimensions.
This CL add the minimum dimensions on several places:
WM core:
1. Verify minimum dimension requirement before adding an Activity to
a TaskFragment. It'll be early return if the requirement is not
satisfied.
2. Propagate the minimum dimensions to the client side through
TaskFragmentInfo to notify the requirement.
3. If TaskFragmentOrganizer tries to shrink a TaskFragment to
the bounds that smaller than minimum dimensions of its children
Activity, switch to match the parent bounds.
AndroidX Window extensions:
1. Early return if TaskFragment is resized to the bounds that smaller
than minimum dimensions which dispatched from the server side.
2. When organizer tries to show Activities side-by-side, verify if
minimum dimensions requirement of the primary Activiy. If the
requirement is not satisfied, show Activities in fullscreen
instead.
TODO: Add an API to check if an Activity intent is allowed to embed
in a TaskFragment.
Bug: 232871351
Test: atest TaskFragmentOrganizerControllerTest
Test: atest TaskFragmentOrganizerTest TaskFragmentOrganizerPolicyTest
Test: atest SplitActivityLifecycleTest
Test: atest CtsWindowManagerJetpackTestCases
Test: atest WmJetpackUnitTests
Merged-In: Ib46c2cec2a0735b9e3f3420f2cb94754801b86b9
Change-Id: Ib46c2cec2a0735b9e3f3420f2cb94754801b86b9
Lower the background opacity when the window loses focus
while the view still has focus, in order to prevent user
confusion in a multi-window environment.
Bug: 230355625
Test: manually verified
Change-Id: I59cd7faf35f05a12451f015f8ef2da47077b1bf2
Merged-In: I59cd7faf35f05a12451f015f8ef2da47077b1bf2
Before this CL, minimum dimensions of Activity wasn't respected,
that said, an Activity could be embedded in a TaskFragment of which
bounds are smaller its minimum dimensions.
This CL add the minimum dimensions on several places:
WM core:
1. Verify minimum dimension requirement before adding an Activity to
a TaskFragment. It'll be early return if the requirement is not
satisfied.
2. Propagate the minimum dimensions to the client side through
TaskFragmentInfo to notify the requirement.
3. If TaskFragmentOrganizer tries to shrink a TaskFragment to
the bounds that smaller than minimum dimensions of its children
Activity, switch to match the parent bounds.
AndroidX Window extensions:
1. Early return if TaskFragment is resized to the bounds that smaller
than minimum dimensions which dispatched from the server side.
2. When organizer tries to show Activities side-by-side, verify if
minimum dimensions requirement of the primary Activiy. If the
requirement is not satisfied, show Activities in fullscreen
instead.
TODO: Add an API to check if an Activity intent is allowed to embed
in a TaskFragment.
Bug: 232871351
Test: atest TaskFragmentOrganizerControllerTest
Test: atest TaskFragmentOrganizerTest TaskFragmentOrganizerPolicyTest
Test: atest SplitActivityLifecycleTest
Test: atest CtsWindowManagerJetpackTestCases
Test: atest WmJetpackUnitTests
Change-Id: Ib46c2cec2a0735b9e3f3420f2cb94754801b86b9
Update View logic to cancel all RenderNodeAnimators
when it is detached from a window.
Updated HWUI Animation logic to enable a cancellation
flag to cancel all animators operating on a RenderNode
whenever the staging parameters are pushed to RenderThread
Fixes: 229136453
Test: Added core test to RenderNodeAnimatorTests
Change-Id: Id674e8474757bfc8dfe30394dde29da49d139bfc
When the size of the drawable bounds changes, the mask shader is not updated properly
Assumed passed by reference instead of pass by value which resulted in
the wrong behavior
Fixes: 227624349
Test: RippleMicrobenchmark
Change-Id: Iedc3f06441414455fcfedf8cabd61e5b334a7441
This reverts commit 47032a209517ccdc50bbcc27b2f4e5bbaaf28552.
Reason for revert: DroidMonitor: Potential culprit for Bug 230140012 -
verifying through ABTD before revert submission. This is part of the
standard investigation process, and does not mean your CL will be
reverted.
Change-Id: I22f5aa5bd57e37d638292773986b479428e5cdbc
Because Bitmap mutability is propagated across Parcel and Binder, the
following problem can happen when sending an Icon containing a Bitmap
as part of a Notification:
1. App creates Icon with a mutable Bitmap (1 alloc)
2. App sends Icon to system_server, often creating ashmem Bitmap (2 allocs)
3. system_server converts ashmem Bitmap back to heap Bitmap (3 allocs)
4. system_server sends heap Bitmap to each NotificationListener individually,
converting the heap Bitmap to ashmem each time (3+N allocs)
5. NotificationListener converts ashmem Bitmap to heap Bitmap (3+2N allocs)
This is inefficient. This is especially bad because the API to update
a Notification involves sending a full Notification object, including
Icons, repeatedly, and some apps do that several times per second.
Instead, ensure that all Bitmaps transmitted as part of Icons are
immutable. Instead, we get:
1. App creates Icon, which may copy to immutable Bitamp (1 or 2 allocs)
2. App sends Icon to system_server over ashmem (still 1 or 2 allocs)
3. system_server uses received ashmem Bitmap directly (still 1 or 2 allocs)
4. system_server sends same ashmem Bitmap to NotificationListeners (1 or 2)
5. Each NotificationListener uses the same ashmem Bitmap (1 or 2)
This solves the per-NotificationListener amplification, but it does
not solve sending what is likely the same Bitmap N times per second
when apps update Notifications. That will require either app changes
or Notification API changes to avoid bytewise comparisons for all
Bitmaps.
Test: boot, notifications work, memory in maps/gearhead remains good
Bug: 227920378
Change-Id: If92835f647a76da599f358c7c02888e3e2f59235
Native machinery now reports queue stalls from native layer
up to java layer, which can more appropriately handle errors.
The first case we handle is the case of "stuck fences", generally
indicating GPU hangs. In this case we trigger a bespoke ANR rather
than waiting for an ANR in dequeueBuffers later. dequeueBuffers
ANR could have any number of causes, and this large cluster
is difficult to debug.
Bug: 216160569
Test: Existing tests pass
Change-Id: I7b4429ce96d0bbfa1b74534ddf2b447facb22d10
In most cases, we do want the destination frame to be updated by BBQ.
The exception is SV due to multiple threads involved in property
changes. Change the default updateDestinationFrame to true and let SV
set it to false for their scenario.
Test: Apps with NATIVE_WINDOW_SCALING_MODE_SCALE_TO_WINDOW work
Fixes: 228008717
Change-Id: I90ae6f0797633aa963c540a94f1cbaea9e498f23
The forceDraw flag in HardwareRenderer will ensure a frame is drawn when
requested even if it would end up drawing multiple frames in a single
vsync.
This is to help blast sync when we want to synchronize the
buffer. We want to make sure we are guaranteed a callback since we don't
want to wait for retries, especially in the case when trying to synchronize
multiple buffers.
There was already a global flag to handle this, but would use the flag
for all draws. This new function is set per draw so once a frame is
drawn it's unset. The global flag was only used for tests so updated the
test to set the flag before every draw and deleted the global property.
Test: Underlying code was in place. This is just piping a new setter. No
usages yet.
Test: TestSceneRunner
Bug: 200284684
Change-Id: Ie1c9950cabb7331cfed1721564a51a1a15cd1624
HWUI already supports disabling RT animations, but there was no correct
way to call it from the application. Adding a call to enable or disable
RT animations on the RenderThread so RT animations can be disabled
during a blast sync.
Test: Builds
Bug: 200284684
Change-Id: Ia1ae3498c38b84b4975f08d37bc764f0c690ed9f
Without this, when font are overlayed it will fail because it is looking
in the wrong place to load the font
Bug: 151770185
Test: Manual, example app that has a font that is overlayed
Change-Id: I64c5a436b7250cfd0a75f5de36c64f07a20d523a
1) Update the LineBreakConfig class to be immutable.
2) Do not return null in the PrecomputedText.Params#getLineBreaiConfig API
Bug: 216638444
Test: atest TextViewTest; atest MeasuredTextTest; atest PrecomputedTextTest; atest TextViewPrecomputedTextTest; atest StaticLayoutLineBreakingVariantsTest
Merged-In: I93bcb6ebc35344e34e9bb8a24df375aa7b3a8d81
Merged-In: I07766137ff6639c7d4acaad07dbcf11a2841cdb0
Change-Id: I07766137ff6639c7d4acaad07dbcf11a2841cdb0
