The metrics we get from Display#getMetrics does not change regardless of
what the new configuration is (we would expect the scaledDensity to change).
Documentation shows that Display#getMetrics is deprecated in R.
Using guidance from b/154665987#comment14 we get the metrics from the derived
context.
Bug: 156141463
Change-Id: I25e5f2c13f94e0471111f6c895694947998e3222
- Init KEY_MIGRATION_SRC_WORKSPACE_SIZE and KEY_MIGRATION_SRC_HOTSEAT_COUNT
- Load default workspace only when default db is created, not when peeking into dbs of other grid options during grid preview / migration
Fixes: 154184711
Test: run grid preview and migration right after a cleared cache Pixel Launcher
Change-Id: I86c7072b8c4a9da76e289c55ab440071f192fc38
> All apps layout broken in landscpae UI
> Crash when manager profile is added
> Wrong icon size on low resolution
Change-Id: If01dacf9f62a0384ebd8b31b62500178416d3ab4
With grid preview, a grid name is passed in when requesting preview under different grid setting. With wallpaper preview, no such grid name will be passed in, and it should be set to the current.
Bug: 145242344
Test: N/A
Change-Id: I282cb5341b7f3756d41c4abd8d97f986abaa6d27
go/grid-migration-preview
With this change, we can see actual grid migration in wallpaper preview.
The approach here: we use a tmp table (favorites_preview) here specifically for this preview (to write off the migration results), and load from this tmp table workspace items if migration is necessary and successful. Otherwise, we load from the current workspace.
UPDATED: this change should be completely compatible with the new multi-db grid migration algorithm. Here is why
1. In LauncherPreviewRender#renderScreenShot, I added a check to decide which grid migration preview method we should call. Once v2 preview method is implemented, it should be integrated with other parts of this change perfectly (the reason will be mentioned below).
2. While we have multiple DBs, mOpenHelper in LauncherProvider always points to the current db we are using. Queries using CONTENT_URI is routed to whatever DB mOpenHelper points to, so it works perfectly to directly operate on CONTENT_URI even when we use multi-db underneath the hood.
3. With 1 and 2 mentioned, I believe in order for this preview change to support multi-db, we only need to implement the V2 grid migration algorithm. Because most of what we are doing in this change is wrapped in GridSizeMigrationTask, it's perfectly safeguarded.
Bug: 144052839
Change-Id: Ie6d6048d77326f96546c8a180a7cd8f15b47e4c4
We'll have a db for each grid option and a db for back up / restore.
TODO(pinyaoting): support back up / restore using the new infrastructure, particularly calls to GridBackupTable should use different DBs when the feature flag (NEW_GRID_MIGRATION_ALGORITHM) is on.
Bug: 144052802
Test: N/A
Change-Id: I644a3e70148bd78204a747a337446a3c038f616f
We build an IDP with no grid size override values. This
allows us to reference the profile measurements so that we can have a
consistent UI for areas that the grid size change should not affect.
Bug: 124967099
Change-Id: I6235862c95800d8f31dbf2de1d12b1fcf4dbd850
The bug is caused by launcher saving the grid name and using that grid name
to look for matching display options. This makes sense when changing the grid
size, but doesn't work well when changing the display size.
Example: Initial Pixel display size is set to Default, so we save "normal" as
the KEY_IDP_GRID_NAME. When we change display size to Largest, the
KEY_IDP_GRID_NAME is still "normal" and so we only look at display options
under "normal". Before this, Pixel with display size set to Largest would be
set to "reasonable".
This should be safe change for Q, and we can have a proper fix when we
officially support changing grid size.
Bug: 131867841
Change-Id: If5f3b0a13b90069973e929024b26bd9b9c45a7d8
A previous change [1] introduced the material library as a static library
for the SecondaryDisplayLauncher. The material library defines a
resource "attr/iconSize" with format="dimension" while Launcher3 defines
a resource of the same name with format="float". The material resource
is being overriden by the Launcher3 resource and is preventing aapt2
from disallowing multiple definitions of the same attribute with
different formats.
This change renames the Launcher3 iconSize so it will not collide with
the material resource.
[1] If183dd35a1d197c4a9a8225a021e36c4f1662587
Bug: 129146717
Test: build success and inspection of generated apk
Change-Id: I5eb54ea606ddcfb47d5150b44906a8707203e905
> Removing unnecessary threading logic and the code was running on main thread anyway
Bug: 118757840
Change-Id: I7a012db5a0dbe2c23bd6ff2cd39679a803731ee8
Device profiles are defined such that the grid size is fixed
and only the icon and text sizes change. For every grid size option
there are multiple display configurations.
Bug: 118758696
Change-Id: I54aac9106c576324b02530913c447e849b4ae1da
Separating InvarantDeviceProfile out of LauncherAppState and creating
LauncherAppState only when it is actually used
Change-Id: I2ee55f53cae01f11203f94675bb5f70c65ad2b9d
> Refactoring RecentsView to a common base class
> Moving some dependency form Launcher to BaseActivity
> Using the Recents view in RecentsActivity
Change-Id: Ie0e6741d356291e77420798c140c999121de3a0d
Derivative projects can extend the FloatingHeader to add support
to custom content in all-apps screen.
Change-Id: I4e29221a72e5a077a756713a6774cda7ecde8f1b
This is the just first CL to get eyes on the changes.
Next CL will update the All Apps to be full width.
Bug: 37015359
Change-Id: I2d7ec6851fdc13b8fa654e7e2be3152330243ccc
- Adding DeviceProfile callback for when the launcher layout changes due
to insets. This is necessary since there are now different layouts
depending on which side the navigation bar is on
- Consolidating hotseat and other layout into the device profile
launcher layout logic
- Making the all apps icons match the workspace icon height
- Tweaking caret drawable to draw to the bounds specified to simplify
layout in each orientation
- Fixing minor issue with page indicator shifting in landscape
- Centering overview buttons to the workspace page
Bug: 30021487
Change-Id: I1866bce00b2948f3edd06168c0f88d81207e3f13
