This CL allows freeform-first devices to lock the taskbar in a pinned
state when Launcher is visible.
Bug: 361419732
Flag: com.android.window.flags.enter_desktop_by_default_on_freeform_displays
Test: DisplayControllerTest
Test: manual
Change-Id: Ic0d2740e33fee19c676d88aa2bcf370eb64366e8
> Making SafeCloseable implementation mandatory, to prevent leaks during test and preview
> Removing getNoCreate method and defining executeIfCreated to avoid null pointer exceptions
> Fixing sandbox value leaking into main, by Checking sandbox against App context
> Converting sanbox to an interface instead a class
Bug: 335280439
Test: Presubmit
Flag: None
Change-Id: I951dcde871898e745ff6490a1c4f8fd1512888f5
- In 3-button landscape/seascape, Launcher should always have nav insets regardless if it's initiated from fullscreen apps
- This avoid inset to change mid-way during app->overview transition via recents button
- This bug doesn't happen in portrait because bottomNav is always overriden in WindowManagerProxy, we're now applying the same fix in landscape/seascape
Test: Recents button from fullscreen app in 3-button landscape/seascape, and launch adjacent fullscreen app in Overview
Test: Homescreen and widget picker in 3-button landscape/seascape
Fix: 316085856
Flag: None
Change-Id: Ia4ae7948fe794b71c49f89c43dd2d1d14031abb9
- Also fix WindowBounds.isLandscape to use full display bounds to determine isLandscape, otherwise both orientation will be treated as isLandscape when using availableSize
Bug: 309801705
Test: manual and presubmit
Flag: NONE
Change-Id: Ic7f4235e620d4760a9af356f23066fe5b23304e6
- In CHANGE_SUPPORTED_BOUNDS check, it uses Map.equals, but as the value is a primitive array WindowBounds[], equals check does not deep compare the arrays and may result in false negative
- One example is when fontScale changes, DisplayController re-create bounds from WindowManagerProxy, result in new WindowBounds[] created, and the shallow compare results in unexpected CHANGE_SUPPORTED_BOUNDS
Fix: 282736623
Test: DisplayControllerTest
Change-Id: I3897595c58559192b951ecfee7c9f62a07dafe1f
When reading the status bar inset on devices with
multiple displays after switching the displays
the inset is not updated immediately (SystemUI
should update the height of the window first by
reacting to the display switch in it's own process).
Due to this race condition Launcher is very likely
to calculate DeviceProfile with incorrect inset
of the previous display first and update it to
the correct one only after SystemUI finished the
window update.
To avoid this adding calculation of the StatusBar
height to Launcher locally using the same utility
method that is used by SystemUI.
Bug: 264656380
Test: manual test that the statusbar height is calculated
correctly in Launcher on a device with two displays, both on
the inner and outer display and different rotations
Change-Id: Ia16ecadd8fcac29082d27ca693ab7740ce6161c4
- Mock WindowManagerProxy instead of IDP in DeviceProfileTest
- Extracted NavigationMode to standalone class
- Moved parseNavigationMode to WindowManagerProxy so it can be mocked
- Moved DeviceProfileTest to internal repo
Bug: 242086027
Test: DeviceProfileTest
Change-Id: Ia5a43293b1380f04d786d2adf8503cfd10f7674a
This will help SysUI test team (who uses TAPL) to set up Gradle build for their tests.
Bug: 202567877, 234414088
Test: presubmit
Change-Id: I3d923ea4b54d1a4c3d2b345be09692727d30433e
- For system Launcher, migrate to use getPossibleMaximumWindowMetrics instead of getDisplays
- Removed usage of displayId
- In estimateInternalDisplayBounds, use CachedDisplayInfo directly as a key
- When cache retunrs null for the current display (e.g. the 3P launcher case), invalidate the cache and estimate again, and only add to supportedBounds if current display is not found in the new cache
Bug: 227459045
Bug: 198965093
Test: manual
Change-Id: Ibcc05ba483ed31a40d16e3cf49c3f3d43af68cf6
Launcher was estimating the landscape insets incorrectly
causing the UI to get reloaded if device is rotated. This also
caused widgets to be refetched as a result of grid size change
Bug: 218067434
Test: Verified locally that the window bounds do not change
Change-Id: Ia7228296c78ea3056f4859e43696d4bfd9522d3c
This code contains utility clases that can change the display
of a device and make it look like another device.
The function DisplayEmulator#emulate receives a DeviceEmulationData
a certain grid to emulate and a callback, everyting that happens
inside of the callback will happen when the device is being emulated
and can be used by other tests.
Example test:
package com.android.launcher3.deviceemulator;
import androidx.test.ext.junit.runners.AndroidJUnit4;
import androidx.test.filters.MediumTest;
import com.android.launcher3.deviceemulator.models.DeviceEmulationData;
import com.android.launcher3.ui.AbstractLauncherUiTest;
import org.junit.Test;
import org.junit.runner.RunWith;
import java.util.concurrent.TimeUnit;
@MediumTest
@RunWith(AndroidJUnit4.class)
public class TestTest extends AbstractLauncherUiTest {
@Test
public void testEmulation() throws Exception {
String deviceCode = "pixel6pro";
DeviceEmulationData deviceData = DeviceEmulationData.getDevice(deviceCode);
String grid = "normal";
DisplayEmulator displayEmulator = new DisplayEmulator(mTargetContext);
displayEmulator.emulate(deviceData, grid, () ->{
TimeUnit.SECONDS.sleep(10);
return true;
});
}
}
Test: You could use the test above to make your device look like a
Pixel6 pro for 10 secons.
Fix: 229028257
Change-Id: Icd79be405a2e14dda0bc5f555b0e46149e16f912
This should make it more configurable, and be independent of the screen size set by the user.
Fix: 223726518
Test: atest Launcher3Tests:HotseatSizeTest
Test: atest Launcher3Tests:InlineQsbTest
Change-Id: If04f3fb0f556103f60b580c757a9fc06da561516
> Moving the code from ApiWrapper to Resource overlays for better maintainability
> Accounting for display cutouts in insets estimation
> Using same logic in display controller and view inset dispatching
Test: Verified on device
Bug: 221961069
Change-Id: I78466353563692ce3f7512b0146ef8b61ef14bc0