This change adds tracking of SoundTriggerService client death
and frees up resources whenever that happens.
Test: Kill Now Playing process and observer recovery.
Bug: 171026874
Change-Id: Ie31d0a3ed392b1513b4e81ec3c344f4e79adcf52
* changes:
Custom binary XML wire protocol.
Progress towards efficient XML serialization.
More efficient alternatives to ByteBuffer.
CharsetUtils alternatives that avoid allocations.
We no longer let apps query the existence of other apps (with some
exceptions). Make sure we honor that by always returning false for the
power-allowlist if the calling app doesn't have the required
permissions.
Bug: 166668654
Test: atest DeviceIdleTest
Test: atest CtsSecurityTestCases:DeviceIdleControllerTest
Test: atest FrameworksMockingServicesTests:DeviceIdleControllerTest
Change-Id: I895f1d666a213e141d9fbf08600c611f04f3a7fd
We've identified that XML writing and reading uses roughly 1.5% of
all system_server CPU, and can generate many temporary objects.
Building on the recent TypedXmlSerializer/PullParser interfaces, this
change introduces new BinaryXmlSerializer/PullParser implementations
that store data using a custom binary wire protocol. Benchmarking of
a typical packages.xml has shown this new binary approach can write
4.3x faster and read 8.5x faster, while using 2.4x less disk space:
timeWrite_Fast_mean: 27946635
timeWrite_Binary_mean: 6519341
timeRead_Fast_mean: 59562531
timeRead_Binary_mean: 7020185
A major factor in choosing to invest in this new wire protocol is
that it enables the long-tail of over 100 unique XML schemas used
across the OS internals to be transparently upgraded to gain these
benefits with only minimal changes, reducing the risks associated
with rewriting those schemas.
Finally, since the wire protocol is essentially a serialized event
stream, it's trivial to transparently convert this new protocol
into human-readable XML and vice-versa. The tests in this change
demonstrate this translation working correctly, and future changes
will introduce new shell tools to aid development work.
Bug: 171832118
Test: atest FrameworksCoreTests:android.util.XmlTest
Test: atest FrameworksCoreTests:android.util.BinaryXmlTest
Test: atest CorePerfTests:android.util.XmlPerfTest
Change-Id: Ib9390701f09562dca952b3786622675b9c68a462
We've identified that XML writing and reading uses roughly 1.5% of
all system_server CPU, and can generate many temporary objects.
To set the stage for some long-term improvements, this change
introduces new TypedXmlSerializer and TypedXmlPullParser interfaces
which offer efficient access to primitive attributes and text.
This change also updates XmlUtils to redirect primitive operations
through these new interfaces.
Bug: 171832118
Test: atest FrameworksCoreTests:android.util.XmlTest
Change-Id: I5ba3ad87cf79ca10705a96b98855164a27fee021
Some upcoming binary XML work needs to efficiently read and write
raw bytes, and we initially started using ByteBuffer. However, that
design had additional overhead since we were performing bounds checks
twice (once to fill/drain buffers, then again to parse data). In
addition, the upstream ByteBuffer makes per-byte method invocations
internally, instead of going directly the the buffer.
This change introduces FastDataInput/Output as local implementations
of DataInput/Output which are focused on performance. They also
handle fill/drain from an underlying Input/OutputStream, and the
included benchmarks show reading 3x faster and writing 2x faster:
timeRead_Upstream_mean: 5543730
timeRead_Local_mean: 1698602
timeWrite_Upstream_mean: 3731119
timeWrite_Local_mean: 1885983
We also use the new CharsetUtils methods to write UTF-8 values
directly without additional allocations whenever possible. This
requires using a non-movable buffer to avoid JNI overhead to gain
the 30% benchmarked performance wins.
Bug: 171832118
Test: atest CorePerfTests:com.android.internal.util.FastDataPerfTest
Test: atest FrameworksCoreTests:com.android.internal.util.FastDataTest
Change-Id: If28ee381adb528d03cc9851d78236d985b6ede16
Create a startSynchronizing() method rather than having this code in the
constructor. This makes it cleaner and its actions more explicit.
Bug: none
Test: manual
Change-Id: I6b84274639ad719ed877f1d04e6621717f860677
BatteryStatsImpl has some recently added methods where formerly we used
A()
now we use
A(int elapsedTime)
Often those old A() calls are now unused and can be removed.
Test: compiles
Test: FrameworksCoreTests
Test: FrameworksServicesTests
Change-Id: I4cac7879db47811ed92455470a660a675db6a4c7
Results:
We measure the latency between Editor.startActionModeInternal is called
and FloatingToolbar.show() is called.
When there is only smart action (url)
Before: ~150ms
After ~30ms
When there are 5 smart actions (phone number)
Before: ~400ms
After: ~100ms
Before and after videos:
https://recall.googleplex.com/projects/ea8c4705-96bd-46f0-9f37-786708050727
Fixed a few issues:
1. updateAssistMenuItems() gets the Icons from TextClassification
object, calls loadDrawable on them and creates the MenuItem
objects loadDrawable() is slow, especially if we have a lot of
smart action icons to load. Even worse, we are calling this
function 4 times in a row when selecting something! 1 time from
onCreateActionMode and 3 times from onPrepareActionMode.
The fix here is to avoid reloading the drawable if it is the same
text classification object.
2. From SelectionActionModeHelper, we call startActionModeInternal
before SelectionModifierCursorController.show()
Internally, SelectionModifierCursorController.show()
show the two selection handles by calling startHandle.show() and
endHandle.show(). Apparently, each handle.show() call invalidates the
action model right after it is just created! This explains two of the
unnecessary onPrepareActionModel calls.
The fix is to call SelectionModifierCursorController.show()
before startActionModeInternal() is called.
3. Editor.startActionModeInternal() does not invoke
FloatingToolbar.show() right away.
There are two issues here.
a) Editor.startActionModeInternal() ends up calling
FloatingActionModel.repositionToolbar() which hopefully calls
FloatingToolbar.show(). Sadly, it is not the case
because mViewRectOnScreen is not set at that time. mViewRectOnScreen
is set in next onPreDrawCall() call.
b) When mViewRectOnScreen is finally set and calls repositionToolbar()
again , it still won't call FloatingToolbar.show() immediately
because we think that the toolbar is moving by comparing the previous
content rect and the current content rect. They are different because
the previous one is empty(it wasn't shown before). Becoz we think it is
moving, we schedule the FloatingToolbar.show() call after 50ms.
To fix a, we now update mViewRectOnScreen() right away wihout waiting
for the next onPreDraw call().
To fix b, when the previous content rect is moving, we don't consider
the toolbar as moving anymore.
Bug: 169043706
Test: atest android.widget.TextViewActivityTest
Test: atest
cts/tests/tests/textclassifier/src/android/view/textclassifier/cts/TextViewIntegrationTest.java
Test: atest
cts/tests/tests/widget/src/android/widget/cts/TextViewTest.java
Test: Smart select a phone number and then smart select a link.
Make sure the smart actions menuitems are updated.
Test: Click on a smart linkify link. Then dismiss it by tapping outside.
Change-Id: I634b21ac7ed66a14883dc17e03ef006df5b3f223
The suspend_control_aidl_interface is updated, renamed, and splitted
into android.system.suspend.control and
android.system.suspend.control.internal. Update to use the correct
interfaces.
Test: atest FrameworksCoreTests:KernelWakelockReaderTest
Bug: 171598743
Change-Id: I32aa339b27f3d9680a61b7338b1bdb531a1a43f7
In order to achieve the look and feel of colored surfaces, the blur
drawable should be able to receive a color and draw it on top of the
blur region.
Test: manual
Fixes: 172372852
Change-Id: I4cab21e337ca18f617780531368ba70154027b72
Move bubbles package and related resources to shell package,
also copied some used codes and resources.
Bug: 161980186
Test: atest SystemUITests
Test: atest WMShellUnitTests
Change-Id: Ia108bd4149b3c3bf86631ba1a7a6bce0e76af78f
to try out different models. In addition, we should not log touches in
the middle of the screen for logging so moving the block at the very
beginning.
Test: unittest, manual test
Bug: 150170384
Change-Id: I6ecb556fea01f26323248b999d17c7b1d1b7eeb7
These are APIs that have @UnsupportedAppUsage but for which we don't
have any evidence of them currently being used, so should be safe to
remove from the unsupported list.
Bug: 170729553
Test: Treehugger
Merged-In: I8285daa8530260251ecad6f3f38f98e263629ca7
Change-Id: I626caf7c1fe46c5ab1f39c2895b42a34319f771a
This introduces BackgroundBlurDrawable that does cross-window blurs
The drawable should not be created manually, it should be retrieved
from the ViewRootImpl
Test: manual
Bug: 159712515
Bug: 171916625
Change-Id: I697e93fc95ba3d0a7211b235b1c5d48a1968b939
In this phase a DisplayPowerController is created per-display. However
each display is still controlled by the default display's
DisplayPowerController.
Bug: 138328918
Test: manual - Boot device and toggle display power
Change-Id: I4c608d1e18476a87d2da4bc1c120d62c39db25eb
These are APIs that have @UnsupportedAppUsage but for which we don't
have any evidence of them currently being used, so should be safe to
remove from the unsupported list.
This is a resubmit of ag/12929664 with some APIs excluded that caused
test failures; see bugs 171886397, 171888296, 171864568.
APIs excluded:
Landroid/bluetooth/le/ScanRecord;->parseFromBytes([B)Landroid/bluetooth/le/ScanRecord;
Landroid/os/Process;->myPpid()I
Landroid/os/SharedMemory;->getFd()I
Landroid/hardware/input/InputManager;->INJECT_INPUT_EVENT_MODE_WAIT_FOR_FINISH:I
Bug: 170729553
Test: Treehugger
Change-Id: I8285daa8530260251ecad6f3f38f98e263629ca7
Update InputConnection#getTextBeforeCursor(int, int) and
InputConnection#getTextAfterCursor(int, int) API to
specify that the paramter {@code n} must be non-negative.
If the IME using the API incorrectly, throw
IllegalArgumentException.
Also update these two APIs that return nullable result (no
behaivor change). For editor App, return null for bad case.
Test: atest BaseInputConnectionTest#testInvalidGetTextBeforeOrAfterCursorRequest
Test: atest InputConnectionWrapperTest#testInvalidGetTextBeforeOrAfterCursorRequest
BUG: 169114026
Change-Id: I95169735198f8363c981a61e20234dfebfd645b1
It should pass mSuspendingPackage instead of mSuspendedPackage as the
parameter of the getResourcesForApplication.
Root cause: The intellij is very smart to provide the autocomplete
options and the developer choose the wrong option.
Solution:
* Add file_pattern in TEST_MAPPING to trigger the CTS tests.
* The developer should take the autocomplete option very
carefully especially the options are very alike.
Fixes: 171835218
Fixes: 171779738
Test: atest CtsSuspendAppsTestCases
Test: atest -p frameworks/base/core/java/com/android/internal/app
Change-Id: I0a213e5fcbf207b89f203e25cf1ace1b8406a879
This is mainly a cleanup, but is also necessary for the
network selection project.
This is for network selection ultimately because NetworkSelection
needs NetworkAgents to use the newer API introduced in R rather
than the legacy internal API. Using that API forbids communicating
to ConnectivityService through NetworkInfo, and does not support
the FAILED state because there is no usage in connectivity.
In VPN, FAILED is used only to communicate a state to Settings
and it does this through IConnectivityManager.getLegacyVpnInfo,
which already is using an int to communicate this information.
Splitting the legacy state from NetworkInfo not only is simpler
ultimately because it's the format in which it's consumed, but
also will allow removing NetworkInfo completely.
Test: FrameworksNetTests NetworkStackTests
Bug: 167544279
Change-Id: I8b95e020919e38a5166892221096db6271985574
Bug: 171417169
Test: Build and make sure protologs still works and sysui gradle
project can build as well
Change-Id: I29684d8b3b5fc49e8179dc15eac9c37cf706322b
