When quick switch a delayed task, before onTaskAppeared called,
if the user holds gesture on nav bar, TRANSIT_WALLPAPER_OPEN from closing
app happens will cancel recents animation when
WC#applyAnimationUnchecked, and that will cause the black screen if the
delayed task not yet drawn and there is no recents task snapshot on top.
Since cancelling recents animation during quick switching doesn't make
sense, to fix that, we should check the animation task target if is
still controlled by recents animation, if so, we should not cancel it.
Also, make sure if the appeared task has already been in task target list,
(i.e. task A appreared, quick switch to task B, before task B appeared,
quick switch back to task A) if so, we don't need to callback task
appeared again.
Fix: 156670249
Test: manual as issue test steps.
Change-Id: I303403d63c91c08fabcb8c5b1b1aac42c4ec65db
1. Add a test api in TvInputManager to add hardware device for testing
2. Add Shell permission for TV_INPUT_HARDWARE
3. Add TUNER_RESOURCE_ACCESS permission for TvInput Framework.
Test: atest android.media.tv.cts
Bug: 155114656
Change-Id: I227f13cbf14532d8732729412ae9c2518755ef02
Without the permission "adb shell cmd uimode night <mode>" doesn't work.
Adding the permission to the AndroidManifest file so the shell command
will work.
Bug: 155584597
Test: run `adb shell cmd uimode night <no|yes|auto>`
Change-Id: Ic444f3351cb130d24a2794284c6bf8709c80712c
(cherry picked from commit a85cc22044)
- Add android.permission.INTERACT_ACROSS_USERS for the CarNotificationLib.
Bug: 156114875
Test: check if SecondayHome is shown (in gcar_hl_md_emu_x86).
Change-Id: I79ae64b90a52235876a6e51ad01ae70def1bf1fa
Convert ACTION_SERVICE_STATE_CHANGED and
ACTION_ANY_DATA_CONNECTION_CHANGED to be non-sticky broadcasts that
require the READ_PHONE_STATE permission to receive. As part of this,
declare READ_PHONE_STATE to be split from READ_PRIVILEGED_PHONE_STATE,
so that system apps holding READ_PRIVILEGED_PHONE_STATE can also receive
these broadcasts.
Also modify affected users to fetch the current value of the broadcast
upon registration instead of relying on the sticky nature of the
broadcast.
Bug: 150155839
Test: manual
Test: atest KeyguardUpdateMonitorTest
Change-Id: I020b1554c4fc59c138d015e787526b4a66c74853
Grant BLUETOOTH_PRIVILEGED permission to test app for Bluetooth testing.
Bug: 155672526
Test: In Kitchen Sink, connect on MAP profile.
Change-Id: I736f5a46e2f198947d7077a5542cf986aea7355c
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
