Settings doesn't actually need to know whether an application
qualifies for a role, but only whether the default app setting should
be visible for an application. Qualification and visibility differs in
cases such as FallbackHome inside Settings which is a qualifying home
activity but should never be shown in default apps UI.
Fixes: 138636320
Test: manual
Change-Id: I216195c64a7b106e2769b11c1a998741a77fdce2
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
Test: Open app and immediately swipe up while opening. Verify
Thread prioties in systrace
Test: WindowProcessControllerTests
Fixes: 137881181
Change-Id: Ic1d7403d2a648e6f1d1b6a3d55b56bf37bc57a2c
Add a DevicePolicyManager method for granting (or revoking) access to a
key for a specific package.
This prevents apps from having to call KeyChain.choosePrivateKeyAlias to
get a grant for the alias.
The motivation for this change is that apps that run as a background
service do not have an Activity to pass into
KeyChain.choosePrivateKeyAlias any more as they are not allowed to
interact with users.
That creates a situation where even though the Device Policy Client
would silently grant the requesting app access to a KeyChain key, the
app still has to provide an Activity.
With this change, the DPC can pre-grant the app access to a key such
that the app does not need to call KeyChain.choosePrivateKeyAlias and
can instead just call KeyChain.getPrivateKey
BUG: 137921026
Test: atest CtsDevicePolicyManagerTestCases:com.android.cts.devicepolicy.MixedDeviceOwnerTest#testSetKeyGrant
Change-Id: I37a75e1f802e223740eb41f055224baba9aa3b3a
See go/UnsupportedAppUsage for more details.
These have already been greylisted, however due to bugs/omissions in the tooling have been kept in go/greylist-txt instead of being annotated in the code.
Exempted-From-Owner-Approval: Mechanical changes to the codebase
which have been approved by Android API council and announced on
android-eng@
Bug: 137350495
Test: m
Change-Id: I5aa29a49b193db47aaee4d3a756c17f48cc9f0b1
