Bug: 148155907
Bug: 135299581
Test: Covered by CTS
We plan to remove Bitmap#createGraphicBufferHandle. Call the new
Bitmap#getHardwareBuffer instead.
Change-Id: I0b3ada9636fcc00df82472ea9479eb0bfbcda9eb
... which is expected when there is no data contributed yet.
Test: atest --test-mapping apex/blobstore
Change-Id: Ib760a184fb17cb39d7d84378416c0e1fba390858
Tests that the screen record tile on/off/cancel works as expected and that the
recording controller updates state and calls listeners correctly
Also updated a couple methods so they make more sense (aren't called
multiple times per event, differentiating between onRecordingEnd and
onCountdownEnd)
Test: atest ScreenRecordTileTest RecordingControllerTest
Bug: 144944929
Change-Id: Ic2d44bbc250bcb1e90eff78839c9ab37c0d93564
In a gambit to improve organization and make other improvements to
NotificationEntryManagerTest, this CL moves the inflation-related tests
to a separate file, leaving more focused unit tests in
NotificationEntryManagerTest.
In the process of doing this, I've also tried to make net positive
changes to how the inflation test works. The summary of changes below.
The Good
* We no longer modify NotificationContentInflater behavior for tests by
telling it to enter "synchronous" mode which probably means we no
longer have to maintain a test-specific path of logic in that class
* We no longer depend on a countdown latch attached as a listener to
know when inflation is done, so listeners breaking shouldn't break all
the inflation-related tests.
* We no longer have the possibility of the test blocking forever from a
TestableLooper#processMessages waiting for a message forever (we just
throw a runtime exception now if it times out)
* Hopefully less flaky since we have tighter control/knowledge on what
messages we produce/wait on.
The Bad
* We now have to use the main thread looper. This is because using
NotificationContentInflater "for real" uses a lot of AsyncTasks which
HAVE to post back to main thread. Since we split the tests though, this
is only needed for inflation-related tests which arguably should be on
main thread.
The Ugly
* The test is more fragile for async/main-thread-related changes as we
depend on knowing the exact number of main thread callbacks to know when
inflation is done. I've tried to mitigate this as much as possible by
having very explicit documentation, but this is clearly less than ideal.
Test: atest SystemUITests
Change-Id: Iff5413cc48167e182f9fdfa0606790c0d4071154
Original commit:
[DexLoadReporter] Report classloader contexts directly from classloader
At the moment classloader contexts are incorrectly computed in the
PackageManager for secondary dex files. There are two issues:
(1) The wrong computed classLoaderContext will be reported for a secondary
dex file if it was loaded at the same time as a primary dex file
- This is due to the continue statement that doesn't increment
dexPathIndex
(2) If a secondary dex file was loaded with a shared library then that
shared library info isn't passed through the dex load reporting
infrastructure, and thus its classloader context is incorrectly computed
in PackageManager.
In order to fix the issues described above & prevent further classloader
context computation divergences between the package manager and the
runtime, lets compute the classloader context in the runtime at dex load
time and report the expected classloader context directly to
DexLoadReporter (and thus the package manager).
Notes: This is mostly just a refactor (i.e. there are a lot of line
changes, but functionally speaking this set of CLs doesn't do much
except change where the classloader context is computed)
Addendum: The bugs described above could also be fixed by:
- changing DexLoadReporter to report information about shared libraries that
the reported classloaders depend on to PackageManager
- Teach DexoptUtils.processContextForDexLoad about shared libraries
- Fix dexPathIndex calculation in DexManager
I opted for this set of changes instead because this reduces the
possibility of context computation divergence between the framework and the
runtime. Additionally it feels more "solid" that the classloader context
is now computed directly when a dex file is loaded, rather than the
context recreated later on in the PackageManager.
Test: atest com.android.server.pm.dex.DexManagerTests
Test: atest com.android.server.pm.PackageManagerServiceTest
Test: Install app depending on shared library & uses secondary dex
files; adb shell pm bg-dexopt-job; launch app and see odex file
successfully loaded (from smaps/no logcat errors)
Bug: 148494302
Exempt-From-Owner-Approval: This is a pure re-revert, previously owner approved.
Reason for revert: Re-land
Reverted Changes:
I295a6e99e:Revert "Fix shared libraries not being reported vi...
Ib58066e8f:Revert "[DexLoadReporter] Report classloader conte...
Change-Id: I8d1af791f93a3f8fa6eca78df50891cd2ebbb4a3
When dragging the cursor...
1) If the touch moves slightly above or below the current line, we keep
moving the cursor along the same line without jumping up and down across
lines.
2) When the drag motion moves downward, jumping to the lower line is
delayed to allow the user's touch to snap to the cursor's handle. Once
the touch is over the handle, we position the cursor above the user's
actual touch (offset such that the finger remains over the handle rather
than on top of the cursor vertical bar). This improves the visibility of
the cursor and the text underneath.
Bug: 148116165
Test: Manually and ran automated tests
atest FrameworksCoreTests:EditorCursorDragTest
atest FrameworksCoreTests:TextViewActivityTest
atest FrameworksCoreTests:TextViewActivityMouseTest
Change-Id: I88432cbc5a7f1a47cd35866f2001d51d3f66828b
