The nGetReleaseNativeFont native method has been moved to the enclosing
Font class. JNI registration also does not occur for
Font$Builder.nGetReleaseNativeFont.
Test: m -j framework
Bug: 230032992
Change-Id: Ic987812cabe57c5c964b3cb8036cd7e297c11c36
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
They are now public API, so they should perform the same checks as in
respective calls with ASurfaceTransaction.
Bug: 210837722
Test: atest SurfaceControlTest
Change-Id: I1f17f8402dc116a419189f31faf351ffa967ecda
Modified SurfaceView and ViewRootImpl to provide callbacks when syncing
a transaction instead of sending transactions. This will ensure a clear
ownership of the transaction object since it will be provided in the
callback when BBQ adds a buffer into the transaction. Modified JNI to
add compatibility for native functions.
Test: Manual testing from go/wm-smoke.
Test: BLASTBufferQueueTest
Bug: 210714235.
Change-Id: I1f872d6b2846b0d64d5b33b8866d0b2ec7126c8c
For Android S, we use the API windowSplashScreenAnimationDuration to
know the duration of the animatable icon would be, however, developers
can be confused to thought that this API is used to declare the
duration of splash screen.
To get the real duration of the animatable icon, if it is an AVD or
AnimationDrawable, try to get the animation duration from it.
Test: atest StartingSurfaceDrawerTests SplashscreenTests
Bug: 211707095
Change-Id: Ia3f8c5cd50bab164360e07d9ced87ff7f4321e96
The caller such as SurfaceView can optionally apply destination
frame changes if they wish to synchronize buffer scale with other
scales in the hierarchy. This is hard to synchronize if the buffer
scale changes, since in fixed scaling mode we want the destination
frame to be applied when a buffer of the new size is queued.
This approach is brittle because SurfaceView does not have control
over the buffer production and the app can get into a scenario
where there is scaled incorrectly.
Fix this by configuring BBQ to always apply destination frame
changes or always defer to the caller. If the scaling mode is freeze,
then BBQ will set a flag to ignore the destination frame. This
allows us to synchronize destination frame changes with scale
applied by a parent and avoid unwanted scaling if the scaling
mode changes to freeze.
Test: atest SurfaceViewTest
Test: go/wm-smoke
Bug: 217973491
Change-Id: I5226c304bae9dde890306f8528dfeabf6b015a32
Also fix a typo in ImageFormat's docs
Fixes: 218928677
Test: make
Change-Id: Icc5d32afac113e639a81a11c86bee1698ef12861
(cherry picked from commit 000c374e2b)
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
Change-Id: I07766137ff6639c7d4acaad07dbcf11a2841cdb0
Call the updated native version of getDisplayDecorationSupport (added in
I961051c0a660b596039ac04b546040764ee20d34), and convert the NDK struct
into a Java class. Depend on the graphics AIDLs, which now have Java
backends. A future CL will update SysUI to call the new API.
Add a PixelFormat for R_8 to correspond to the native version. This will
allow SysUI to use COLOR_MODE_A8 when the HAL reports R_8.
If64fd6924960f592b7a211371bc2ca6536ae34f7 demonstrates using this.
Bug: 216644902
Test: manual
Change-Id: I0e34c6d6e369fda0a96231ab38c3bd5f3bfe3e06
