These operations are used by MediaProvider when checking and noting
interactions with specific media types on the device.
Bug: 137890034
Test: atest --test-mapping packages/providers/MediaProvider
Change-Id: Id452ad121bd8a0b7c1c337a2b7fe030135a9d776
We already have startOp() and finishOp() to provide a mechanism to
mark an operation as being "active". This change publishes a set of
APIs to check the status of these active operations, matching the
naming of similar existing APIs on the same class.
Bug: 139128842
Test: atest com.android.server.appop.AppOpsActiveWatcherTest
Test: atest android.media.cts.AudioRecordAppOpTest
Exempt-From-Owner-Approval: trivial API refactoring
Change-Id: I9fb381d748ff23ff24dd363ed5b117bd661793ab
These are all pieces of data apps could get anyway;
these are code nice-to-haves to reduce code replication
Test: make
Bug: 122138479
Bug: 138589409
Change-Id: Ie8ffacb6c28840f779c68f7aa95f1405e70f5ce5
Split the single method for granting/revoking key access into two
methods.
Bug: 139091816
Test: cts-tradefed run commandAndExit cts-dev -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.MixedDeviceOwnerTest#testSetKeyGrant
Change-Id: I495f35419a5dd1c12e18703f11dd4216a310430d
Add ability to give 'startup-agents' that are automatically loaded
when a (debuggable) app starts. These agents are any files in the
'code_cache/startup_agents' directory. The agents are started with the
apps data_directory as an argument.
Test: Install debuggable apk (here com.antonioleiva.bandhookkotlin)
walleye:/ $ run-as com.antonioleiva.bandhookkotlin sh
walleye:/data/data/com.antonioleiva.bandhookkotlin $ mkdir code_cache/startup_agents
walleye:/data/data/com.antonioleiva.bandhookkotlin $ cp /data/local/tmp/libtifasts32.so code_cache
walleye:/data/data/com.antonioleiva.bandhookkotlin $ cp /data/local/tmp/libtifasts64.so code_cache
walleye:/data/data/com.antonioleiva.bandhookkotlin $ cp /data/local/tmp/libchainagentss32.so code_cache/startup_agents/
walleye:/data/data/com.antonioleiva.bandhookkotlin $ cp /data/local/tmp/libchainagentss64.so code_cache/startup_agents/
walleye:/data/data/com.antonioleiva.bandhookkotlin $ echo $PWD/code_cache/libtifasts32.so=log,ClassLoad > chain_agents.txt
walleye:/data/data/com.antonioleiva.bandhookkotlin $ echo $PWD/code_cache/libtifasts64.so=log,ClassLoad >> chain_agents.txt
Start bandhookkotlin
Examine logcat
Bug: 135627501
Change-Id: Ib82b27df90c7964a995288d8b2b3d348a11cdd80
(cherry picked from commit c0fce111c8b7c68ddb397ac7c65ac5c35a40da01)
* changes:
Sysui/WifiTracker: Changes to support late starting wifi service
WifiManager: Retrieve IWifiManager service lazily
WifiStackClient: Register wifi API services from system_server
Mainline wifi stack module
NetworkStackClient: Refactor network stack process interaction
Wifi services will be initialized a little later in the bootup sequence
because it is now a separate APK. So, retrieve wifi services lazily
(on the first method call on the object).
This will alleviate the need to modify all the clients which instantiate
WifiManager very early in the bootup sequence (Sysui, some vendor apps,
etc).
Bug: 137374831
Test: Device boots up & connects to wifi networks.
Change-Id: I8e1f0eb3a5a8fdb79b088447fbb9f97413f64483
Merged-In: I8e1f0eb3a5a8fdb79b088447fbb9f97413f64483
Include the RSS info into the meminfo output of dumpsys and
incident_report.
Bug: 117880513
Test: adb shell dumpsys meminfo
Test: cts-tradefed run cts-dev --module \
CtsIncidentHostTestCases --test \
com.android.server.cts.MemInfoIncidentTest
Change-Id: Id1058e279b7ca6925b59a6a523e0f0d14d830761
CL [1] introduced ActivityView's surface view set alpha as zero by default.
but SurfaceView ignores alpha value by default.
So to archieve SurfaceView can support alpha value and then introduced CL[2].
with that CL, it will affect ActivityView that can't see the surface because
of this zero alpha value.
Since CLs[1] & [2] are mainly considered for BubbleController to implement
content visiblity with setting surface view's alpha value without
flickering, and in BubbleExpandedView#onFinishInflate has already
called setContentVisibility(false) to set ActivityView's alpha value as
zero before add this view.
So removing ActivityView's default zero alpha value would be fine, since
it may not always the case that need to set zero alpha but need to show
the black rectangle surface for user. (i.e. ActivityViewTest or Android Auto)
Also, refined ActivityView#setAlpha for some stuff to make it clear.
[1]: Ie5aed373996419b059935889b564ca91c2e3cf23
[2]: I86847de59109b2adf12a2c7c50c988c2cbcf0450
Bug: 137937105
Test: manual as below steps
1) make & install ActivityViewTest
2) launch "AV Main" shortcut
3) press "Test ActivityView" -> "Launch test activity"
4) see if launched Acitvity is visible as expected.
Test: atest ActivityViewTest, observe if ActivityView is visible during testing.
Change-Id: Iaf480912f06a6851001a42bf90e4d962c8a88a37
For backward compatibility, SurfaceView ignores alpha value by
default. In order to reflect alpha value set on the SurfaceView
to its underlying surface, setUseAlpha() needs to be called.
Translucent alpha only works when the surface is placed z-above.
Otherwise only fully opaque and transparent status are supported.
Bug: 137937105
(Orignal bug from b/130442248)
Test: Manual, use BubblesTest app and checks if alpha is set.
Change-Id: I86847de59109b2adf12a2c7c50c988c2cbcf0450
In preparation of moving the jobscheduler framework code to its
own jar.
Bug: 138793378
Test: dumpsys batterystats -c | grep jbc and make sure the line looks correct
Change-Id: I9938c99e37bd44e522e5f8d8e95772e69d5be492
As the main javadoc states:
"An app can check whether wallpapers are supported for the current user,
by calling {@link #isWallpaperSupported()}, and whether setting of
wallpapers is allowed, by calling {@link #isSetWallpaperAllowed()}."
Test: manual verification on automotive
Test: atest CtsAppTestCases:android.app.cts.WallpaperManagerTest # on automotive
Bug: 138939803
Change-Id: I88946f92ff54e556d289c41c28e22da3a4b8c8b8
Force SurfaceFlinger to update synchronously by applying an empty
transaction. Without this, SurfaceFlinger will only update after the
next vsync, which may only happen after the instrumentation already
starts.
Since InputFlinger will only have the proper InputWindowInfo after
SurfaceFlinger updates, waiting for the vsync caused some
instruemntation tests to be flaky.
Bug: 138263890
Test: atest android.view.cts.HoverTest
Change-Id: I5457ab67ac574530dc1aa84549ca11e7e3f0d714
CL [1] introduced ActivityView's surface view set alpha as zero by default.
but SurfaceView ignores alpha value by default.
So to archieve SurfaceView can support alpha value and then introduced CL[2].
with that CL, it will affect ActivityView that can't see the surface because
of this zero alpha value.
Since CLs[1] & [2] are mainly considered for BubbleController to implement
content visiblity with setting surface view's alpha value without
flickering, and in BubbleExpandedView#onFinishInflate has already
called setContentVisibility(false) to set ActivityView's alpha value as
zero before add this view.
So removing ActivityView's default zero alpha value would be fine, since
it may not always the case that need to set zero alpha but need to show
the black rectangle surface for user. (i.e. ActivityViewTest or Android Auto)
Also, refined ActivityView#setAlpha for some stuff to make it clear.
[1]: Ie5aed373996419b059935889b564ca91c2e3cf23
[2]: I86847de59109b2adf12a2c7c50c988c2cbcf0450
Bug: 137937105
Test: manual as below steps
1) make & install ActivityViewTest
2) launch "AV Main" shortcut
3) press "Test ActivityView" -> "Launch test activity"
4) see if launched Acitvity is visible as expected.
Test: atest ActivityViewTest, observe if ActivityView is visible during testing.
Change-Id: Iaf480912f06a6851001a42bf90e4d962c8a88a37
