This change adds nearby-area searching when dragging desktop items into already-occupied cells. This approach tries harder to find a matching area, instead of strictly rejecting invalid moves.
We also draw a "snag" during the drag to show where an item would be dropped, but only if we would drop into an alternative cell. This gives users better feedback about where things will drop.
http://b/issue?id=1634887
*** Reason for rollback ***
Roll back US Spanish import because it made the build too big.
*** Original change description ***
Import US Spanish translations, and a few Japanese changes.
Automated import of CL 144355
Done by using small button framework assets, but with manual padding adjustments to bring back to original button size.
Original author: jsharkey
Merged from: //branches/cupcake/...
Automated import of CL 143792
Done by using small button framework assets, but with manual padding adjustments to bring back to original button size.
Original author: jsharkey
Merged from: //branches/cupcake/...
Original author: android-build
Merged from: //branches/donutburger/...
Automated import of CL 143816
During the first boot upgrade, LauncherProvider will deleteHost() to clear out any old appWidgetId bindings. During the first boot, Launcher calls AppWidgetHost.startListening() to watch for widget updates. It also calls loadUserItems(), which loads data from LauncherProvider, triggering the database creation and deleteHost() call. Because deleteHost() removes any existing callbacks, any future widget updates are dropped on the floor. (This can currently be solved by rebooting, because there isn't an upgrade on subsequent boots.)
This bug was particularly evident on vfpioneer-userdebug builds, as there aren't any configuration changes that cause Launcher to be destroyed and recreated. (When destroyed and recreated, we startListening() again, and LauncherProvider doesn't call deleteHost().)
To handle this special case, Launcher creates a ContentObserver pointing at a specific URI, which the LauncherProvider notifies when the AppWidgetHost is reset through deleteHost(), allowing Launcher to correctly startListening() again.
Original author: jsharkey
Merged from: //branches/cupcake/...
Automated import of CL 143776
During the first boot upgrade, LauncherProvider will deleteHost() to clear out any old appWidgetId bindings. During the first boot, Launcher calls AppWidgetHost.startListening() to watch for widget updates. It also calls loadUserItems(), which loads data from LauncherProvider, triggering the database creation and deleteHost() call. Because deleteHost() removes any existing callbacks, any future widget updates are dropped on the floor. (This can currently be solved by rebooting, because there isn't an upgrade on subsequent boots.)
This bug was particularly evident on vfpioneer-userdebug builds, as there aren't any configuration changes that cause Launcher to be destroyed and recreated. (When destroyed and recreated, we startListening() again, and LauncherProvider doesn't call deleteHost().)
To handle this special case, Launcher creates a ContentObserver pointing at a specific URI, which the LauncherProvider notifies when the AppWidgetHost is reset through deleteHost(), allowing Launcher to correctly startListening() again.
Original author: jsharkey
Merged from: //branches/cupcake/...
Original author: android-build
Merged from: //branches/donutburger/...
Automated import of CL 143789
Done by using small button framework assets, but with manual padding adjustments to bring back to original button size.
BUG=1749120
Automated import of CL 143746
During the first boot upgrade, LauncherProvider will deleteHost() to clear out any old appWidgetId bindings. During the first boot, Launcher calls AppWidgetHost.startListening() to watch for widget updates. It also calls loadUserItems(), which loads data from LauncherProvider, triggering the database creation and deleteHost() call. Because deleteHost() removes any existing callbacks, any future widget updates are dropped on the floor. (This can currently be solved by rebooting, because there isn't an upgrade on subsequent boots.)
This bug was particularly evident on vfpioneer-userdebug builds, as there aren't any configuration changes that cause Launcher to be destroyed and recreated. (When destroyed and recreated, we startListening() again, and LauncherProvider doesn't call deleteHost().)
To handle this special case, Launcher creates a ContentObserver pointing at a specific URI, which the LauncherProvider notifies when the AppWidgetHost is reset through deleteHost(), allowing Launcher to correctly startListening() again.
BUG=1746104
Automated import of CL 143622
Only happens when user changes orientation while editing, where getFolderById can return the wrong folder type for the given ID.
Original author: jsharkey
Merged from: //branches/cupcake/...
Automated import of CL 143232
Only happens when user changes orientation while editing, where getFolderById can return the wrong folder type for the given ID.
Original author: jsharkey
Merged from: //branches/cupcake/...
Original author: android-build
Merged from: //branches/donutburger/...
Automated import of CL 143382
Eric Fischer