This article outlines the process of compiling your GameMaker Studio 2 project into an Android .aab or .apk file which can then be uploaded to one of the multiple Android stores (like Google Play or Amazon).
Actually compiling a package is very straightforward as long as you have previously set up GameMaker Studio 2 for testing and can get your project to run on your test device(s). If you haven't already gone through this process, please see the following article and then return to this one:
Once you can test on a device you are almost ready to build your game package, but first you need to take a moment to revise the different Game Options.
Android Game Options
The Android Game Options can be opened from the Asset Browser's Options menu (just double-click on the Android entry), and it's here that you set up all the details for store-ready packages:
In this article we'll only run through the import parts of the Game Options for building the final game package, but you can find complete information for each section from the GameMaker Studio 2 manual.
To start with let's look at the General Settings...
The most important things to fill out here are the Product Information and the Build Settings. The product information will be used to define how the product will be identified on the store being uploaded to, and you should give it a Display Name (which will be used on the Store and for the Icon name on Devices), a version number (always greater than any previous version you may have uploaded), as well as a unique Package Identifier. The Package Identifier is a reverse-url format identifier that is normally configured as "com.<CompanyName>.<GameName>".
IMPORTANT! This ID uniquely identifies your app on the device and in different stores. If you want to upload a new version of your app, the application ID must be the same as the original package file which was uploaded. If you change the application ID, the different stores will treat the new submission as a completely different app. So once you publish your app, you should never change the application ID.
You can see in the example image below how this could all look:
With the Product Information filled out, you should check the Build Settings next. If you've successfully been testing with a device then you probably won't need to change these, since if it builds for testing it should build for the final packaging, but it's a good idea to revise them and make sure that you are setting them correctly (see our Required SDKs FAQ for our current recommendation and to ensure you are using supported tools versions).
You should note, however, that if you are using any extensions you may need to bump the minimum SDK value up to whatever the Extension requires (check the documentation that comes with the extension).
Finally, you will likely want to change the Architecture options before you upload to a store. With the architectures, you can select the ones you want the game to target, with the obvious choice being to select them all to get the widest coverage of devices. However, each different target architecture will add to the size of your final package and so may be considered extra bulk for little gain (especially with bigger projects that may not run well on lower end devices anyway).
IMPORTANT! For submitting to Google Play you must have the Arm64 architecture enabled, otherwise you will get an error when trying to review your uploaded .aab file that it does not support 64bit devices.
Before compiling the game you should also check and make sure that the Graphics options are correct:
Important things to check here are the Screen Colour Depth, Device Support and Texture Page options. With screen colour depth, if you choose 24bit then your gradients and glows will be much smoother and subtle with less "banding", but it comes with a cost as it will also impact on performance. Note: this setting does not mean that your project won't run on a device with 16bit colour display; it will, but it may mean it's using extra resources for no gain.
With Device Support, you are telling GameMaker Studio 2 to target either devices with a dedicated GPU or any device. There is no hard and fast rule here for which to choose, but if your game is using any surfaces, extended blend modes, 3D graphics, or is a large resolution project (like 1080p) then you probably want to only support devices with a GPU.
For the texture page size, again, there is no strict rule for this, but given how fragmented the Android market is you are probably better choosing a smaller size than a larger size (if in doubt, simply leave it at 1024x1024). However, choosing too small a size may impact performance as it can increase the texture swaps required, but too large a size may mean that your graphics get distorted on devices that have less vRam and so the texture is scaled down to fit in memory and then scaled back up to be drawn). Ideally, you should have a low end and a high end device to check these things.
Icons And Images
The Icons and Images sections of the Android Game options are where you set the different promotional images that your game will use on the different Stores. Each image should be authored as a PNG file and set to the size given, and they will be used as promotional Icons, as well as on-screen icons and splash screens when your game has been installed on the end users device.
There is also a section for Adaptive Icons:
Android 8.0 (API level 26) introduced adaptive launcher icons, which can display a variety of shapes across different device models. For example, an adaptive launcher icon can display a circular shape on one OEM device and display a "squircle" on another device. Each device OEM provides a mask, which the system then uses to render all adaptive icons with the same shape. Adaptive launcher icons are also used in shortcuts, the Settings app, sharing dialogs, and the overview screen.
These icons are comprised of a background image and a foreground image, which can be supplied to the Game Options so that GameMaker Studio 2 can generate the required icons automatically, or you can supply individual images for each. The adaptive icons section of the Game Options also permits you to preview the different possible mask types to ensure that the final icons will look correct regardless of the device showing them.
If your game is going to be uploaded to the Google Play store, then you have the option of adding Licensing from the Packaging options. Adding a Licensing Public Key here will help "lock down" your game to the Google store, and prevent unauthorized distribution - and it may also be required if you have any type of in-app purchases in your game project. Note that this will require you to have set up the app listing on the Google Play Console previously and obtained your licensing key from there.
Note that Google Play Licensing is only useful if you are actually publishing to Google Play and you should not enable it if you wish to publish to other stores. So, you may want to make two packages - one to upload to Google Play with Licensing enabled, and one with licensing disabled for the other stores.
In most cases you should not have to change anything shown on the Permissions section of the Game Options. These should be set automatically for you when using GameMaker Studio functions, but if you are using any third party extensions then you may have to select a permission manually.
See the documentation that comes with the extensions you're using in this project.
The final section of the Android Game Options is related to the different Social extensions that can be added to your game. These should have been selected before you reach the stage of compiling your game and will have downloaded extensions from the Marketplace to activate them.
As mentioned above, some of these may require you to change the Minimum SDK API value in Game Options > General > Build Settings section.
Compiling Your Game
Once you have the Game Options correctly set up you are ready to compile your game as an APK or as an AAB ("Android App Bundle") for uploading to a store.
IMPORTANT! Nowadays, Google Play require an AAB file for their store, however all other stores still require an APK.
You can compile the game using either VM or YYC, although we recommend that final executables always use the YYC as it can give an important boost to performance. Note that YYC builds may take longer to compile than VM.
When you click the compile button you will be prompted to select a location to save the final file to, and here you can also select whether to build an APK or an AAB:
Once you have selected the file type and the save location, the compilation of your game will begin. You should note that the compile process may need to connect to the internet to download additional files and tools, which in turn may prompt a firewall alert - if this happens you should allow the connection otherwise the build will fail.
Once the game has finished compiling, GameMaker Studio 2 will open the folder containing the created package, ready for you to upload.
Publishing Your Game
Once you have your package built you are ready to publish your game to any one of the numerous Android stores. The two main stores are Google Play and Amazon, and both of them require you to sign up as a developer beforehand. You can find out more from the links below:
Note that there is a small fee attached to becoming a developer with these sites. Once you've signed up, you will normally have to make an "App Listing", fill out some details and then upload the APK. In some cases, like if you want to use Google Play Licensing, you will have to have created the app listing before compiling the final APK file.
The actual details of the app submission progress for Amazon and Google are covered in the following articles: