which has been superceded by AggegateBatteryConsumer
Bug: 186006876
Test: atest FrameworksCoreTests:com.android.internal.os.BatteryStatsTests
Test: Use BatteryStatsViewer to verify that it's still functional
Change-Id: I2e4fe36ff310b6d68923fcecdfd22ce865b1f32d
Fixes: 186758538
Relnote: "Removes edge effect type from the API -- EdgeEffect now
supports only stretch edge effect for all applications."
Test: existing tests, modified to work with stretch
Change-Id: Iec7a9d4a0316ff3ba7297c4565bb881a1adcf949
The implementation for drag-and-drop provides two ways of taking URI
permissions: a public API that ties permissions to an activity and
an internal API that grants "transient" permissions. The latter is
used in a single code path: dropping content into an editable
TextView (implemented in android.widget.Editor).
The transient code path was previously (Android R and below)
implemented using a try/finally block in Editor.onDrop. The change
I7ae38069fb741925211b42c7ff28784eb9722ce3 had updated that logic to
tie permissions to the app process lifecycle instead, to account for
the new OnReceiveContentListener which apps can use to implement
custom drop handling (and use a background thread to do the processing
of the content). The problem with having permissions tied to the app
process lifecycle is that the app process could potentially be
long-running.
This change updates the logic to tie transient permissions to the
DragAndDropPermissions object lifecycle (release whenever there are no
more reference to the object and it is garbage collected). This
follows the same approach as used for IME permission grants
(InputContentInfo.java and InputContentUriTokenHandler.java).
Bug: 181178998
Test: atest CtsWindowManagerDeviceTestCases:CrossAppDragAndDropTests
Test: Manually verified using development/samples/ReceiveContentDemo
Change-Id: I950d4572ee19af64da1ace1572fe12e17d09c609
as opposed to SystemBatteryConsumers, which will be removed
in a follow-up CL
Bug: 186006876
Test: atest FrameworksCoreTests:com.android.internal.os.BatteryStatsTests
Change-Id: Ie4166217be211d92293c2a107762801a7d3c206f
It turns out that IInputMethodManager#reportActivityView() [1], which
was added a few years ago to support CursorAnchorInfo API on edit
fields hosted on an ActivityView [1], is now also used by task
organizer [2]. This means that we would continue living with this
@hide API for a while even after ActivityView gets completely removed
at Bug 179161778. Then, converting this IPC into truly asynchronous
would probably make sense.
There should be no behavior change unless the target IME client is
running on an embedded display environment.
[1]: Id0411a80456182111bb5b681c6d1230b58e7ec2e
b4f328a2f3
[2]: Id422bb2547197c617f914ed7cf5085e02a1c3fb5
a1f869d10e
Fix: 186874025
Test: atest CtsWindowManagerDeviceTestCases:ActivityViewTest
Change-Id: I0463e8e9daaa8ab6d3eadb395843ca5e6bc1bb5e
For consumers who don't care about blocking package data updates and
only need data at a specific snapshot in time, these methods would
avoid locking PMS during the iteration process.
Bug: 183643808
Test: atest com.android.server.pm.test.verify.domain
Change-Id: Ia951381798d75f77c4ad5fc010a469b69992f074
We now have two notions of profileable:
* profileable from shell: the user can profile the app using ADB-based
tools (e.g. Android Studio or shell) . This is off unless the app
opts in.
* profileable from platform services: trusted platform services can,
in accordance to the app installer's Terms Of Service profile the
app. This is the default unless the app opts out. This is enforced
by the profilers with information provided by the framework.
A new flag <profileable android:enable="false"/> can be used to opt out
of profiling in general. If this is not given, the app is considered
profilable by the platform, but the data will *not* be exposed to the
user via shell or adb. If profiles of the app should be given to the
user (e.g. for using Android Studio), <profileable
android:shell="true"/> can can still be used.
We write whether the app opted out or not to packages.list, to be
consumed by the profilers.
CTS-Coverage-Bug: 186720347
Test: m
Test: on userdebug: /data/system/packages.list for preinstalled, Play
Store installed app and sideloaded app.
Test: on user: atest CtsPerfettoTestCases.
Bug: 170284829
Change-Id: I8d4bbedc043976fd11a95a511bd95a05c7ced7b9
Previously these two states in AMS are being mapped into the ImpFg
in the ProcStats, we were unable to distinguish them in the aggregated
proc stats. Now with these two new states in ProcStats, the process
states we're using in AMS could be mapped into them, and eventually
get mapped into the state definition in the aggregated proc stats.
Bug: 186438656
Test: atest ProcStatsValidationTests
Test: atest ProcessStatsDumpsysTest
Test: atest CtsIncidentHostTestCases:ProcStatsProtoTest
Test: atest CtsStatsdHostTestCases
Test: atest CtsAppTestCases:ActivityManagerProcessStateTest
Change-Id: I94eaa18d9c99f90200603fd0aafe198b62e963f7
Create colors using CAM16 hue and chroma, L*a*b* L*,
and map them to RGB without distortion.
Test: atest FrameworksCoreTests:com.android.internal.graphics.cam
.CamTest, all passed. No link, atest/my build are broken and cannot
upload results.
Bug: 186640057
Change-Id: I64b605dd452d64e57be0047d2e4672917c01c2a8
Patch action:
Add the state or content description into the corresponding feature target.
Bug: 178289063
Test: atest AccessibilityTargetAdapterTest AccessibilityTargetAdapterTest
Change-Id: I2f421da027bc95021ab24cadf8b3afdc30fa6d4a
-. Remove VoidResultCallback of applyImeVisibility.
and let it be truly asynchronous.
-. Rename this method to applyImeVisibilityAsync.
Bug: 183587528
Test: atest CtsInputMethodTestCases
Change-Id: Ica564c526223d32641a2485c0c0f3490fe4bfd39
