* Generic AOSP devices don't set it and we don't really
want to fork them just to set the bootanimation size.
Change-Id: I684454ae07348ee29c832f86f56bcfbd4f627b4d
Some systems seem to have with the convert command as-is:
convert: Cannot write PNG8 or color-type 3; colormap is NULL
Because we are writing PNG8, there area a max of 256 colors total.
Explicitly telling convert to stay under the max fixes the issue.
Change-Id: I595fb4503396ca20226ea76bf7b15ed9878752fd
Make sure that any changes to the boot animation can be picked up
and rebuilt by running 'mka bootanimation.zip'.
Change-Id: Ice10e919df4c1b651c5c5dbb9700cab38eeac748
The servers do not have ImageMagick installed right now,
breaking the automated builds.
Revert this for now.
This reverts the following commits:
840e781408 bootanim: Use a for loop to make part# folders
ce5405d1f7 Fix wrong bootanimation.zip from mkdir .../part{0..2}
6179d9494f cm: Build bootanimation.zip
67ddf37281 cm: Rework boot animation generation
Change-Id: I63fc43da9b1a6afea5f791e879f0bfc9a385d98d
For some reason the mkdir command:
mkdir -p $ANDROID_PRODUCT_OUT/obj/BOOTANIMATION/bootanimation/part{0..2}
creates a directory part{0..2} instead of three separate directories.
Non-fatal build errors and a 386 byte bootanimation.zip file result.
This explicitly creates each directory.
Change-Id: Ia6ae0e4f64521992de8cc34a376af3eaac5c8819
