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
