This is an implementation of long screenshots supporting
interactive, incremental capture of scrolling content using
a cooperative API between the app process and the system.
Design goals:
- Provide for tile based incremental screenshots of scrolling content
- Support existing apps without developer action
- Provide support for non View-based Apps & UI toolkits
Bug: 148131831
Test: atest \
FrameworksCoreTests:android.view.ScrollCaptureClientTest \
FrameworksCoreTests:android.view.ScrollCaptureTargetResolverTest \
FrameworksCoreTests:com.android.internal.view.ViewGroupScrollCaptureTest \
FrameworksCoreTests:android.view.ScrollViewCaptureHelperTest \
WmTests:com.android.server.wm.DisplayContentTest
Merged-In: I6c66a623faba274c35b8fa857d3a72030a763aea
Change-Id: I6c66a623faba274c35b8fa857d3a72030a763aea
In quick switch flows, launcher will first swipe task snapshot
through recents animation, and then start new task with custom animation
options through startActivityFromRecents after gesture finish detected,
and then finish recents animation finally.
But that way user may experience flickering before the new task launch
and recents animation finish.
To improve quick switch flickering, we ignore the new task's custom
animation from recents and generate task remote animation target,
and then trigger a callback for launcher to control/animate this
task surface, more like a part of RecentsAnimation,
Also, adding removeTask method for launcher can flexibility remove the
new task animation target once no need to animate, so that launcher
can decide when to finish recents animation.
Bug: 152480470
Test: manual as below steps:
1) Doing quick switch task.
2) Make sure launcher can receive onTaskAppeared callback.
3) Make sure launcher calls removeTask successfully.
4) Make sure launcher can finish recents animation after 3).
Change-Id: I0692a280a49719229fa8871509bad37a1343a00f
The root causes of this issue are:
1. WindowTokenClient#attachContext makes WindowTokenClient has strong
reference to WindowContext, which leads to WindowContext cannot be
GC'd.
2. WMS#removeWindowToken needs MANAGE_APP_TOKEN permission which
normal apps don't hold.
This CL does following things:
1. Use weak reference instead on WindowTokenClient#mContext.
2. Relax WMS#removeWindowToken to check callingUid if
MANAGE_WINDOW_TOKEN permission is not held
3. Deliver config changes to the client side in
WMS#addWindowTokenWithOption
4. Some minor fixes
fixes: 150812449
Bug: 150715095
Test: atest WindowContextTest
Test: atest WindowManagerServiceTests
Test: atest WindowTokenTests
Test: atest WindowManagerPermissionTests#testMANAGE_APP_TOKENS
Test: atest
WindowManagerPermissionTests#testADD_WINDOW_TOKEN_WITH_OPTIONS
Change-Id: I9f1d73af2abb78fc9844e6d9eb25e9f0293514e7
Support addWindow with the other userId which can be different from Uid.
This can be used when client want to addView for secondary user.
Example:
1. Create context with createContextAsUser or similar method.
2. Get WindowManager with this context.
3. WindowManager#addView
Bug: 151414297
Test: atest WmTests WindowAddRemovePerfTest AddWindowAsUserTest
Change-Id: I13e58d76b1f056f3829bc984c2b61496c8f8d535
Even DeadObjectException is thrown, it is not equivalent to the
window is died (transaction failed by small size data will be
DeadObjectException). Sometimes it may be caused by the binder
buffer of process is temporarily full. If the window is removed
directly but the process is still alive, the application client
and window manager are out of sync. Especially if the window is
important system window, e.g. status bar, notification shade,
navigation bar, which might need to reboot to recover. Ideally,
if the process is really dead, there should be a binderDied
callback that also removes the window.
The original purpose of the removal is to avoid display frozen
(e.g. rotation) always timeout which is caused by resetting
WindowState#mOrientationChanging in each layout traversal. Now
the window states are still updated as "resized" has reported,
so it won't block unfreeze display.
Bug: 151814107
Bug: 147448299
Test: atest WindowStateTests#testReportResizedWithRemoteException
Test: Hard code to throw RemoteException for a specified window
and rotate the display.
Change-Id: Id295456cc99ab9af30aa5fad2eedada6afb862a2
Renamed TaskContainers to TaskDisplayArea and added getDisplayArea()
method to WindowContainer that finds the first display area in the
hierarchy above the node. ActivityRecord and Task override it to
return the TaskDisplayArea class.
Bug: 152116619
Test: WM CTS and unit tests
Change-Id: I4525afbcd794848e1020213cdca04d89a646dd55
This is a important broadcast that needs to be picked by multiple
components and apps.
Bug: 152655546
Test: build and sanity
Change-Id: I17befbb8814c09c24498b4e534e04f0fbce24c2f
The UserSystemPackageInstaller (USPI) uninstalls system
packages that are not needed, depending on the user type.
When that determination changes (or the feature is disabled)
it can also re-install those packages.
This cl specifies when it is appropriate for USPI to actually
perform the (un)installation.
1.
Introduces uninstallReason: records the reason why a package
was uninstalled from a given user. Right now, the only values
are UNKNOWN and USER_TYPE. The latter indicates that the USPI
system uninstalled the package. If the USPI whitelist changes
(or the USPI feature is disabled), uninstalled packages will
only be installed by USPI if the uninstallReason was USER_TYPE.
Any further uninstalls (e.g. by ManagedProvisioning) will reset
the uninstallReason to UNKNOWN, so USPI will no longer install
such packages in the future.
This prevents USPI from reinstalling system packages that other
mechanisms (such as ManagedProvisioning) uninstalled.
2.
USPI will uninstall a system package if it is blacklisted, but
only if that system package is new, i.e in two circumstances:
a. on first boot
b. on an OTA where the package was not present prior to the OTA
Bug: 143200798
Test: atest UserSystemPackageInstallerTest
Test: Confirmed (un)installations during manually simulated OTAs
Change-Id: Ia0714d1faa8f7c79082f2cc93a92ae36b9a4c918
Merged-In: Ia0714d1faa8f7c79082f2cc93a92ae36b9a4c918
ANGLE is a system library which adds a developer option to control when
it is used as the default OpenGL ES driver.
Test: manual, ANGLE.apk's developer options work.
Bug: 142239747
This is a cherry-pick of https://android-review.googlesource.com/c/platform/frameworks/base/+/1222890
Change-Id: I3e616d6252d0daa0e32c942b05987d17e73a2709
So we can test system APIs in cts.
Bug: 150952758
Test: atest android.media.tv.tuner.cts.TunerTest
Change-Id: Ife5a5f712cdf3d3c2e5dd747fa1d3bc8c165b85b
Permisssion of PanService#setBluetoothTethering is change from
BLUETOOTH_ADMIN to BLUETOOTH_PRIVILEGED.
Tethering service need bluetooth privilege permission to enable
bluetooth tethering.
Bug: 146045934
Test: on/off bluetooth tethering
Merged-In: Ib87a5d5a5bb49390aa55e52713bb3539d4a52348
Change-Id: Ib87a5d5a5bb49390aa55e52713bb3539d4a52348
This permission is needed for wifi CTS tests.
Is the minimally scoped permission that needs to be added?
- Yes, this only allows the app to influnce wifi vs lte network
selection algorithm.
What options did you explore that did not need this permission?
- Without this permission, it would be impossible to test these API's:
WifiManager.setWifiConnectedNetworkScorer()
WifiManager.clearWifiConnectedNetworkScorer()
WifiManager.clearWifiConnectedNetworkScorer()
WifiManager.addOnWifiUsabilityStatsListener()
Bug: 150236894
Test: Device boots up.
Change-Id: Ic173e44ab818cdfecebde80715ddaec347019db6
Add MODIFY_DEFAULT_AUDIO_EFFECTS permission to shell which
is needed to run GTS tests on @systemApis for
audio effects control.
Bug: 148703417
Test: run gts -m GtsAudioTestCases -t com.google.android.audio.gts.DeviceEffectTest#testCreateDeviceEffect
Change-Id: Iba579001aeffd85743850727135a6f536579ea17
- This is a *temporary* permission that we are using to set the system
rotation setting via the launcher settings. The framework uses the
same setting for forced-rotation, but this currently only is scoped to
launcher so it makes more sense as a launcher setting than as a
developer option (and we plan on removing it shortly). We are working
with jjaggi@ and caen@ to coordinate the fw and launcher settings.
Bug: 151611270
Test: Manual
Change-Id: If371cac4d580785ed1714c82a67b995a40ecf9a6
CaptivePortalLogin is not a privileged app, so it cannot get these
permissions anyway.
Test: CaptivePortalLogin working without the permissions
Bug: 151214275
Change-Id: I283b8068b9eada28d92c9d550473106a1b680a27
Merged-In: I283b8068b9eada28d92c9d550473106a1b680a27
(cherry picked from commit 53839762d4)
The hidden API is used by SystemUI process to adjust the system UI based
on when a certain camera is opened or closed.
Test: Manually observe callbacks in SystemUI when running camera CTS
Bug: 150540299
Change-Id: I04cae782d96f0e32be8ef588dcd328f84b32887a
The dialog can only be requested if the package of the controls provider is
currently in the foreground.
This is accomplished by querying Activity Manager about the
UidImportance of that package. Added
android.permission.PACKAGE_USAGE_STATS to SystemUI for this.
Test: atest
Test: manual
Fixes: 149410221
Change-Id: Ifdf479d8dbc70502da95d362e3bfd60ad3c561fb
This was suggested by the share sheet team and I checked that this
permission only narrowly adds the ability to present a nicer share
target.
The default print service cannot be renamed "print" as the name of the
app shows up on other print UI.
Bug: 150646365
Test: Checked permission after boot
Change-Id: I3aa5900605bda90ce0cb58a09fe08128bf4c9531
Make REGISTER_STATS_PULL_ATOM permission available to Shell to allow
testing it in gts.
Is the minimally scoped permission that needs to be added?
Yes, it is the only permission to register pulled atoms.
What options did you explore that did not need this permission?
I explored expanding the permission to be development in addition to
privileged, and giving the permission to gmscore. However, this solution
was recommended to me by the GTS team. If there are better ways to enable
testing the API in GTS, I am open to feedback.
Test: atest GtsStatsdHostTestCases
Bug: 150329323
Change-Id: I103d937842beaa2d918181b1a952d27179411dcc
This permission is needed for some wifi CTS tests.
Is the minimally scoped permission that needs to be added?
- Yes, this only allows the retireval of the saved wifi network
credentials on the device.
What options did you explore that did not need this permission?
- Possibly creating a UI to ask for manual entry of network credentials.
But, that would not let us do automated CTS tests (will need to become
CTS verifier tests then).
Bug: 150236894
Test: atest android.net.wifi.cts.WifiNetworkSpecifierTest
Change-Id: I6881003510191f667950be1ab27a5399fe3914b4
Add the required permissions for querying PlatformCompat to the
whitelist for TelephonyProvider.
This is the minimum scoped permission -- PlatformCompat only defines two
permissions for access (read and write) and we need both.
The alternative for using these permissions is to not call
PlatformCompat and enforce the new behavior on all apps. This was deemed
unacceptable by the app compat team because it was breaking some popular
apps.
Bug: 144631034
Test: atest TelephonyProviderHostTest
Change-Id: I43a0a66ae381caf8d9e21d0f14d471b20a4e44af
1. This is a minimally scoped permission (which allows the new WiFi API's
to silently connect to a wifi network).
2. I explored writing a GTS test instead of a CTS test, with the idea being that it would run inside the Android Auto user. Unfortunately the API under test requires two permissions, MANAGE_COMPANION_DEVICES and COMPANION_APPROVE_WIFI_CONNECTIONS. Android Auto will only have COMPANION_APPROVE_WIFI_CONNECTIONS, and if I elevate to Shell privileges the test will have MANAGE_COMPANION_DEVICES, but not COMPANION_APPROVE_WIFI_CONNECTIONS. Beyond this, I've been told that it's better for us to test this API in CTS than what it is under GTS.
The addition of the permission to androis.os.shell could theoretically allow it to connect to a WiFi network using the new WiFi APIs without the user being prompted. Android R will still allow the legacy WiFi API's which also allow wifi connections without users being prompted without this permission. Android Auto requires the new API's as they better handle cases of connecting to WiFi networks with no internet access. The old API's will not always result in fallback to LTE, whereas the new ones do that.
Test: Unit test in separate change.
Change-Id: Ifd8ae6b7e53307ea8973406fdefa468dfa679bda
Bug: b/147748710
