If a wallpaper preview is going to look exactly the same as the actual wallpaper
on the homescreen page that is being returned to, fading looks much nicer than
the default activity exit animation.
Bug: 23568800
Change-Id: Id7c2b5483c5535d59be2f8a459ce7788e3c8318a
To get the crop, the wallpaper is first scaled down as much as possible (i.e.
until either the width or height matches that of the device screen), then a
center crop is performed (the excess width or height is chopped off). The
preview's parallax was previously incorrect if the width was the victim of this
cropping, because in that case the parallax started and ended at a different
point than in the actual wallpaper. This is fixed by adjusting the parallax of
the preview to match the final crop.
The end result is that all wallpaper previews match the actual wallpaper upon
setting, except for the default wallpaper because it follows a different flow.
Bug: 23568800
Change-Id: I82b7ba506d51ee4b3812af5fbdf95d3303b37aef
This is less prone to error, because calling setParallaxOffset() multiple times
will always lead to the same result. Plus, this works regardless of whether
moveToLeft() was called first.
While the parallax offset ensures that previews of built-in wallpapers match
the actual wallpaper you get upon saving, it does not work in all cases.
Specifically, it does not work for a couple (1 or 2 on the devices I've tested)
of the larger built-in wallpapers. However, this seems to be due to a mismatch
between the size of the preview wallpaper and the actual wallpaper (the latter
is larger). This sounds like a separate bug.
Bug: 23568800
Change-Id: I69afa3f8cc59c77e9c4c25e29e8db8c4beb87462
When "Wallpapers" is selected from the overlay, the current wallpaper parallax
offset is sent to the WallpaperPickerActivity as an Intent extra. The CropView
then uses that offset when previewing new wallpapers to ensure the preview looks
exactly the same as the actual wallpaper will when set.
Note that this fix doesn't seem to work for DefaultWallpaperInfo - that will
come in a future CL.
Bug: 23568800
Change-Id: I41c5bbbfdabfeb4e20d77e9b5804842a03211edf
> Moving different tiles to individual classes
> Moving some utility methods to corresponding tile classes
> No functionality change
Change-Id: I493cf309f4e3d817a9300be004c475d208f8dadb
Previously, if you selected a photo to set as the wallpaper multiple times, it
kept adding temporary wallpaper tiles that were all identical. Now it reuses the
same tile, updating the thumbnail and wallpaper if the Uri happens to point to a
new image (such as if a photo is renamed).
Change-Id: Ib05c9db4e1fd17226b503174f25add3368158b11
This will enable an easier migration to the new M APIs for identifying
button presses from stylus / other tools.
Bug: 20430722
Change-Id: I41cfa6eff8d76bb83cf1bdaf6623ec1092ed554c
> Only setting desired size on wallpaper change for pre kitkat
> Removing wallpaper change receiver from manifest
> Removing multi-process wallpaper shared prefs for kitkat+
Bug: 23353784
Change-Id: Iba72d32871ee50b75807e2284a73a691bcddc472
> Using system implementation of ExifInterface to read orientation
> For inputstream, creating a temporary file with just the header
since the system API only supports file input
Change-Id: I19c94ff28e9d9bac14cd9b717de0ff165ba95595
> Renaming Lmp to Lollipop
> Lollipop_MR1 instead of directly using 22
> Using M APIs directly instead of reflection
Change-Id: I10a307f46e3be15b3299f549a2fd7e0e215a6a1b
If reading the rotation setting without the multi-process flag, the
WallpaperPickerActivity usually picks up a cached value. Specifying the
multi-process flag during the read fixes this and the wallpaper picker
always has the correct rotation setting.
Change-Id: Ic3639f8cd694674e92c8940b753c6bc30486076d
This updates almost(*) all locations that use a long press listener to
also set a custom touch listener that recognizes the stylus button press
action.
The stylus button press action is: when a stylus touches a view while the
primary stylus button is pressed which may occur on a DOWN or MOVE event.
*The location this is *not* enabled for is: Longpress to enter "overview"
mode -- this isn't really a selection or drag n drop action; it is also
easy to accidentally do this while using the stylus gesture to drag n drop
items which is not an ideal interaction. Also not set for the "cling" that
demonstrates this.
Bug: 20430722
Change-Id: I9343f143261a7b4fada9afca28b8a11a60dbecca
This CL adds a Settings activity along with the code needed to provide
a "Allow Rotation" setting to all phones and tablets. This setting is
set to false for phones and true for tablets. On changing the setting
from unlocked to locked, the launcher (and the Settings activity)
will get locked to the orientation the user was in when he disabled
"Allow Rotation". This is consistent with how the natural rotation
feature of Android works.
Change-Id: I8a1c59d1fa0bb9262530cad96e0a9bdbab0d9344
> Fixing some RTL errors by specifying both marginStart and marginLeft
> Moving all layout direction checks to Utilities
> Explicitely adding @TargetApi before every method
Change-Id: Ibe9c52b93b5a6adeadb27ace2b312770fd732ea0
Elimates 304 methods based on dex analysis
The java compiler generates sythetic accessor methods for all private
fields, methods and contructors accessed from inner classes. By marking them
package-private and @Thunk instead, sythentic accessor methods are no
longer needeed. These annotated elements should be treated as private.
Change-Id: Id0dc2c92733474250d8ff12fa793d3a8adeb1f26
> Loading preview bitmap only once, instead of loading it twice at BitmapRegionTileSource and BitmapSource
> Maintaing a weak-set of reusable bitmaps and reusing them for decoding bitmaps
> Loading images on a HandlerThread (instead of AsyncTask) and removing any non-started task before submitting a new task
> Loading inbuild images (from resources) on HandlerThread instead of UIThread
> Freeing up unbound GL textures before binding a new texture.
Bug: 18382606
Change-Id: Ic4ca630dd113ded65d2853eb0d291c9e5823637e
(cherry picked from commit 283c2261bd)