Update from the future
After some months, Epic Games added a more useful way to create multiple apks without worry about the StoreIds for each architecture and compression value, so, unless you need to support more than one texture compression format, i don’t recommend to use this app (use ETC1 it’s not that bad… use ETC2 if you are using Unreal Engine 4.25 since OpenGLES2 support have been deprecated, so, less formats to take care of n_n).
Also, using Jenkins (this is what we are using right now) or another CI/CD tool facilitates the creation and distribution of the projects binaries.
The problem
The release of BusterBusterBus (a new game i’ve been working at GoldenPie Studio) that’s almost here, testing is almost done… and a important question to answer: What architecture and with what texture format are we going to launch our game?
Actually… We don’t know for sure. During development (we move from Unity to Unreal Engine 4) we experiment with different formats in Android and due to different kinds of GPU vendors (and OpenGL support), it became a little difficult to choose. Acording to Android documentation, we could just stuck with ARMv7
(32 bits) and use ETC1
as texture format (since it’s the default format for every Android device) and call it a day, but we already see the other formats in action and we liked the results.
At first that mean we’re going to use Android:Multi
to package our game and that’s it… but not quite. Right now, one APK built for ARMv7
with ETC1
textures is only ~79MB (apk size, not installed size), versus ARMv7
with Android:Multi
, which have an average size of ~194MB (Almost x2.5 bigger). As a developer is easier to just package an Android game with Android:Multi
(we make just 2 APks, one for ARMv7
and another for ARMv8a
) and keep moving forward, but it’s a no brainer what the average user it’s going to prefer (the less size, the better). But what if what if we want to create all the versions posible? Well, 12 APKs await for us (and it’s no fun creating all those APKs… believe me, I’ve done it before).
The proposal
A simple application that create all the APKs that we need (so we can choose what Architecture and Texture format want to support), and sets the store version value and other common options for us.
The objective seems clear we just need to know:
- Where the project is.
- What texture formats am i going to export.
- What architectures do we need to support.
Since we’re going with python then PyQt5 was the way to go for our UI.
To build all those apks we made use of RunUAT, an Unreal Engine helper script. Unfortunatly there’s not so much documentations but no worries, we can use the log to see all the parameters used by the editor.
After some digging, reading the source code and some trail and error, we ended with that command:
|
|
Command and arguments to launch the RunUAT script.
Even if it looks like a lot of work for the task, there’s another incentive to justify the creation of the app. The unreal engine create a different apk for each architecture that checked in the project settings. If we want to support more than one ARM architecture (Google is asking to start uploading apks with ARMv8 native support, and that means different StoreID as Google explains here -> Multiple APK support), we can use this little project to automate the StoreID generation (More info about that in the Repository of the project, link down below) for each apk created.
Final words
That’s all from me. I enjoy building the app (I’m still learning how to program with python or make small tools that help us in our day to day jobs) and for me, a relief a lot of work and time generating all those APKs for the current game and future games and releases can be saved. If you’re interested in the project, you can clone it here -> Gitlab Repository.
Thank you for reading and see you later.