GitLab

Launcher2 on sw720dp devices had 8 hotseat slots; Launcher3
has only 6 on those same devices. When importing the old
hotseat, the empty slot (so technically there were 9)
occupied by the all apps button didn't line up with the new
all apps button, causing a hole on the hotseat. Furthermore,
the icon in old position 3 was clobbered by the new all apps
icon:

    0 1 2 3 (#) 4 5 6 7 ==> 0 1 2 (:) _ 4 5

In this CL we introduce a separate sort-and-place step for
hotseat icons so that any icon colliding with the new
all-apps slot can be moved to the right to find the next
nearest open slot. This works well for the 8->6 case; it
will probably do something reasonable, if not ideal, for
other grid migration scenarios.

But those are not covered by this bug.

Bug: 13015468
Change-Id: I7edb3f27addc78ad02bbfcd1c39175ca56220007

Merge "Revert "Fix issue of extra blank screen after uninstall (issue 12372657)"" into ub-now-lunchbox

This reverts commit b2603e3d.

Change-Id: I81f8c5a4e3861b936ef9e1fbdb339c12d5aefc70

Change-Id: Iddcdf655c78b7240be123bd549f3d45794d02c83

Change-Id: I0326914821f68d789cb26767518ead1292d87db0

Change-Id: I17944c557970ed35e1bc67f6f3e3372ff88651ad

Merge "Avoid stripping empty screens if the workspace is still loading (issue 12523285)" into ub-now-lunchbox

When opening the picker, the currently chosen wallpaper is
shown in the background.
In this change also the nullpointer was fixed when deleting
the currently selected wallpaper and setting it, because we
revert to the old wallpaper in that case.
When going into the same live wallpaper than the currently
selected we are going back to home if the user sets it or
goes back now, in order for the user not to loose state.
The real fix for this will be done later when the following
bug will be fixed: b/13241760

Bug: 12063773
Bug: 13219612
Change-Id: I7c6abb25755eca99c3255278e0884d1ff4749b55

Deal with WallpaperManager.getBuiltInDrawable() returning null.

Bug: 13109487
Change-Id: Ib5665a0eb947e9784cdcd0e8dfab1a01b4deca82

-> This appears to be what may be causing data loss in some users during update.
   A certain (seemingly) rare combination of life-cycle events and package events
   seems to be the culprit (potentially why it's seen at update time).

Change-Id: Iea4f8aef012ba80b7ba568e0df264edb9284efbe

Bug: 13219313
Change-Id: I4961c6724a1550dbae126f97e45dc166cbe9a565

Bug: 13153542
Change-Id: I4312ebd200e8e652ef841f54301981c2a486b726

This reverts commit f3a8e8c0.

Bug: 12978354
Change-Id: I11f1eeaab4fad9a2e4acf835144f0b0dc6fac54b

Merge "Updating Read/Write settings permission protectionLevels. (Bug 11372484)" into ub-now-lunchbox

Bug: 12953091
Change-Id: Idc640532e2c2c6143d49d330bd541682eca64ac5

Change-Id: I2b7248218fe16856a9721b8b9169700977f19d00
Auto-generated-cl: translation import

-> Also removed the db-created as a criteria for showing the clings
   (this was a bit problematic in some cases and going forward)
-> Instead, we use database upgrade as a signal to not show the clings.
   This is used instead of the above criteria (to prevent old users from
   seeing the migration cling and losing their data.)
-> Stripped some old code related to custom clings that's no longer used.

Change-Id: Ib5e5285e5ddbc60e69eb998ee9fd092ae879150d

am 9594e887: (-s ours) am 37fe7d2b: (-s ours) am f42cf7de: (-s ours) Import translations. DO NOT MERGE

* commit '9594e887':
  Import translations. DO NOT MERGE

* commit '37fe7d2b':
  Import translations. DO NOT MERGE

* commit 'f42cf7de':
  Import translations. DO NOT MERGE

Change-Id: I6fb7884fae6cc8e09ca5fe51f28f5f80b183e9b5
Auto-generated-cl: translation import

Change-Id: I4fb41af97a881f6669af15ddd6db1af4f3429765
Auto-generated-cl: translation import

Bug: 10778992
Change-Id: Ie430a6587d49dc0d78b87b81582c0cef7c281017