Wrong background splashscreen color when generating Android Bundle (.aab) instead of .apk

[albertopq]

Hi there,

When generating my apk, the splashcreen color wasn't showing correctly. Then, following the FAQ, I added the --keep-raw-values option and everything worked fine.

The problem is when generating my release in a Bundle (.aab) format, in order to upload it to the Play Store, the final apk extracted from that bundle it doesn't seem to take into account the option added to build-extras.gradle.

Any suggestion?

Thanks for the great work

[timbru31]

Ugh, tough question. Can you show the steps you are using to build the .aab bundle? (e.g., via Android Studio, CLI commands, cloud services, ...)

[albertopq]

Sure! I'm generating the bundle in Android Studio, on Build -> Build Bundle (s) / APK (s) -> Bundle Then I'm extracting the apk (simulating what the Play Store does) using bundletool (https://developer.android.com/studio/command-line/bundletool) like this:

java -jar /path/to/bundletool-all-1.8.2.jar build-apks --bundle=/path/to/app-debug.aab --output=/path/to/output/built-apk.apks --mode=universal

Then you can rename the built-apk.apks to zip and extract the apks. If you install that apk, the color is wrong. If you build from the beginning an apk, it works :/

Thanks for your help!

[albertopq]

Based on the buildtool documentation, it seems that it already includes its own aapt2 version. I haven't found a way to pass options to that execution, but even if we find it, it won't solve my problem as is the Play Store the one who is executing buildtool :(

Now I'm trying to find a way of specifing the color without being modified by aapt2.

I'll let you know any findings.

Thanks.

[timbru31]

Thanks a lot for your debugging. It's a shame that this issue still persists.
One workaround would be to find an adjacent color that does not have leading zeros and which is close enough so it remains unnoticed by the user.

I'll try to open an issue with bundle tool that the issue still persists.

[timbru31]

Ok let's get creative here:

It seems we need to include the custom --keep-raw-values somehow. The documentation of bundletool says it allows a custom--aapt2=path flag. I haven't fully dug through the code yet, but could you maybe alter this flag?

Of course you'll need to find the AAPT2 location first, but you could try to change it to:

--aapt2="/wherever/aapt2/lives --keep-raw-values". Just an idea that comes to my mind.

[albertopq]

Hi @timbru31,

Thanks for taking a look to this :) The problem with the last solution (already tried it), is that is Google the one who executes bundletool when I upload the .aab into the Google Play Store, so I cannot manage the --aapt2=path

Fortunately, I got a solution! The thing is that is not a bug itself. What is happening is that aapt2 takes the color value as an hex, and so it takes it as an Int (so removing the leading 0 makes sense) and not a String. The solution is as easy as forcing the value to be a string, so:

<preference name="LottieBackgroundColor" value="\#00e0b6ff" /> instead of <preference name="LottieBackgroundColor" value="#00e0b6ff" />

does the trick 🥳

*IMPORTANT: this value breaks iOS, so it should be only under android.

Give it a try and may be it makes sense to update the documentation with this workaround.

Thanks!

[timbru31]

Awesome, this is great news. I'll leave this issue open as a reminder to update the example and/or FAQ

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[timbru31]

Not stale, still needs an investigation.