This fixes an issue when starting an activity that occldues
Keyguard with the window flag from an activity that is already
occluding Keyguard. Normally we wait until the transition starts
until the next activity had a chance to set its layout flag
(FLAG_SHOW_WHEN_LOCKED) with the UnknownVisibilityController.
Now, since setAppVisibility(false) was called after immediately
starting the activity, we removed the activity immediately from
the UnknownVisibilityController waiting list and then unoccluded
Keyguard.
We fix this by only removing the activity from the waiting list if
the app is actually hidden and not just because it's hidden by
Keyguard.
This regressed from I745e985766a1af97203e1d22b6443dabdd0c0363
because calling setVisible(true) was setting the token's visible
to true. Then, setVisible(false) was NOT ignored anymore.
Previously it was just ignored because the app wasn't made visible
yet from WM perspective.
Test: go/wm-smoke
Test: android.server.cts.KeyguardTransitionTests#testNewActivityDuringOccluded
Test: Launch camera from Keyguard with animation transition scale
set to 0. (regression test)
Change-Id: I36ec1bf335c48baf298e78620381bdd0be34aa1d
Fixes: 65061212
Bug: 37677242
If we are about to unocclude Keyguard, we already use its
orientation spec such that if both Keyguard and the activity
going aways share the same orientation spec, there is no
unnecessary orientation change.
Test: Launch SHOW_WHEN_LOCKED portrait activity, hold device
in landscape, toggle power button twice, press home, make sure
no orientation change when animating to Keyguard.
Test: go/wm-smoke
Change-Id: Ic5f110747de5f5f7d73adf83f5f53c7fd56d860c
Fixes: 38146081
* CachedBluetoothDevice's member mVisible does not mean whether the
device is visible. Instead, based on its current usage in the library,
it indicates whether the device was just discovered by SettingsLib.
* Rename the field to mJustDiscovered and associated setters and
getters.
* This paves way for future addition of mVisible to indicate whether the
device should be visible to user in the UI.
Bug: 34685932
Test: build only, no functional changes
Change-Id: I616904e6d5bb27dbae74f94819eb0e8607a16e20
This prevents cached scores from being held indefinitely and used for
SSID fallback logic in WifiTracker (Picker).
Bug: 63073866
Test: runtest --path frameworks/base/packages/SettingsLib/tests/integ/src/com/android/settingslib/wifi/AccessPointTest.java
Change-Id: Ib351d20db30dfd18b69bb1f8e4d4f26fc6b74ef0
Merged-In: Ib351d20db30dfd18b69bb1f8e4d4f26fc6b74ef0
- When calling enterPictureInPictureMode(), the state of the activity in
the client may be out of sync with the state of the activity in the
system, causing an exception to be thrown erroneously. Instead, fail
silently in the system if this occurs, and throw the exception in the
client when it attempts to enter PiP from an invalid state.
Bug: 63753007
Test: android.server.cts.ActivityManagerPinnedStackTests
Change-Id: Ia99cc086805edc31f997d4325f7a5ccd7c85a77e
Bug: 64851247
Drawing to software bitmaps does not support many
features, most especially hardware bitmaps. This
changes the implementation to using hardware bitmaps
for View snapshots.
Also fixed broken TransitionTest discovered while
testing.
Test: I4ede02db67e578ea4a25069b683f1989c611e06c
Change-Id: I185bbfe1f789055c9efdba5297a74e481607afaf
In several places we compute the sha256 of the app's signing certificate
(instant cookie storage, backup account permission grants, static shared
lib matching). It is possible that an app is singed with multiple certs
which unfortunately can appear in a random order. We were using only the
first certificate to compute the hash which may be problematic for apps
signed with multiple certs which are later reordered. If an app update's
certs are reordered for cookie storage the app would not be able to
access the cookie, for account grants the app would not get the grant,
and for shared libs the app would fail to install due to a missing lib.
Test: all cookie CTS tests pass
all static shared lib CTS tests pass
added test that cookie data not lost on sha256 computation change
added test that lib install works when specifying
multiple certs
bug:64270295
Change-Id: Ib6b55f25da735ff5c2762faf6e9b5888e749041d
All snapshots are now stored using only the low resolution bitmaps
where all full size bitmaps are disabled to be written or loaded.
Bug: 62251652
Fixes: 63940837
Test: manual - open recents on low ram device to see if thumbnail is
there
Change-Id: I2128f0348cf71415721e73c730d3ed92e95d8144
Docs change only, no change in logic.
We do not support calling #addJavascriptInterface until after JavaScript
is enabled via WebSettings#setJavaScriptEnabled. Calling these methods
in the wrong order is undefined behavior (and we've seen that it's buggy
under certain conditions, e.g. if the DOM includes an <img> element).
This clarifies the point in the docs and code example.
Bug: 64899039
Test: make -j40 docs (everything looks good)
Change-Id: I8ef9eec7f038037e6b898286e4dad8a57ecad472
(cherry picked from commit aaef6827ca)
