Before the new insets system, a window wouldn't receive visible insets
if it:
- has FLAG_LAYOUT_NO_LIMITS,
- is not TYPE_WALLPAPER or TYPE_SYSTEM_ERROR, and
- is not in multi-window mode.
This CL makes the visible insets compatible with the legacy insets
system.
Fix: 223536648
Test: atest InsetsStateTest
Change-Id: Ia73142cfae701d0532a9a397366c50aeef82abb2
Otherwise, the latency_tracker must be manually
enabled via a SystemConfig (and the device must
minimally be debuggable).
Test: manual
adb shell device_config put latency_tracker enabled true
adb shell am broadcast -a com.android.systemui.latency.ACTION_FINGERPRINT_WAKE
Fixes: 227491682
Change-Id: Ia5a7f2f9eec619c26583bcac6b00b8445abdcbf1
This CL fixes the issue where WM CTS is causing ANR in ARC.
When a menu panel is opened, the sub window for this panel is
created, but as it doesn't have any content, it's considered hidden
by SF. The problem here is that as focus has already moved to this
app at this point, InputDispatcher expects the window will get a
content soon, but this never happens and causes ANR.
So, the root problem here is that PhoneWindow creates a window with
WRAP_CONTENT even if there's no content set to the window. This
seems to be a pure bug in PhoneWindow because there's already some
logic where if it doesn't have any menu item, it aborts opening a
panel, but if this function is called twice, this return logic is
bypassed and the window is accidentally created (because whether
it goes thought the return logic depends on whether st.decorView
has an instance, and this is instantiated in the first call of
openPanel())
This CL ensures the sub window isn't created if there's no item to
be shown.
Bug: 180566381
Bug: 181543065
Test: atest CtsWindowManagerDeviceTestCases
Change-Id: I1a1ae84abf4e4466ebb4a6655a5be007ee763d78
(cherry picked from commit 45ae74eab8)
Merged-In: I1a1ae84abf4e4466ebb4a6655a5be007ee763d78
Use new status_bar_height_default for
SystemBarUtils.getStatsusBarHeightForRotation().
Bug: 216782082
Test: make
Change-Id: I6376169bfeb470de5dc820b9c3633c64981079f0
In 12L, to support mulit-display devices, we changed the way to get the
status bar height by adding an API to calculate instead of directly
reading the resource of status_bar_height.
However, some apps still using Resources.getIdentify() to get this
internal resources dimen as status bar height to layout their UI which
cause status bar glitch in their app.
For compatibility purpose:
1. Create a new dimen res status_bar_height_default which will be used
by framework to determine the status bar heigth
2. For status_bar_height
- Set the value to the size which already consider the cutout size
for defualt display as before so that it won't breaking existing
app.
- It is only used for apps using Resources.getIdentifier()
Bug: 216782082
Test: verified on the apps with such issue.
Change-Id: I306efa187ffa69223c06fd248cfe57d183f96c59
Currently widget provider info are loaded from the manifests of
respective packages, which is not performant since loading the
resources from various apps could take a while.
This CL does the following:
1. Instead of persisting only the providers that are bound to the
workspace, we persists all providers.
2. In addition to providers, we also persists the provider info to avoid
loading them from app's resource during a reboot.
Bug: 202356231
Test: atest AppWidgetServiceImplTest
Change-Id: I91fead0b61b0cb84d876dd05781a585805a01400
Fix the issue that the screen title name of the app language page is
displayed incorrectly
Bug: 227285277
Test: Verify the issue by testing between the system language and app
language page
Change-Id: I229b9ff2defb68d70248a95886d8600e1bc464ea
Now that these methods are no longer called, and none of them are a
public API or have @UnsupportedAppUsage, they can be removed.
inCryptKeeperBounce() actually had one known app user via reflection,
despite the method not having @UnsupportedAppUsage. However, that user
only made the call if Build.VERSION.SDK_INT < VERSION_CODES.P, so it is
not being used anymore.
Bug: 208476087
Change-Id: Idc218e5f355bb61257b07cf5b5b6df5f4c6ece11
configureMiniResolverContent incorrectly calls directly
into safelyStartActivityInternal, which bypasses calls to
StrictMode#disableDeathOnFileUriExposure.
Change-Id: I1c66f659b7d5276caf892b15b942bee5c6f7ead7
Also changes the SYSTEM_CHANGES notification channel to be IMPORTANCE_DEFAULT (by deprecating the existing, unused one).
Bug: 225373531
Test: manual by forcing the notification to show
Change-Id: I9743fe08cccbd8b6a9e7b367e32fe3e597b81ec4
Merged-In: I9743fe08cccbd8b6a9e7b367e32fe3e597b81ec4
