Android SDK


Download & Installation

Github Repository

Use the download button below to download SDK files from Github.


Unzip the files and add all files inside the GA/jar folder your Android Studio project in the relative paths specified below (where NAME_OF_MODULE could be ‘app’ or whatever your module is called).

  • NAME_OF_MODULE/libs/gameanalytics.jar Java library.


Unzip the files and import the gameanalytics.aar inside the GA/aar folder and import it by doing File->New->New Module…->Import .JAR/.AAR Package and the select the .aar file where you downloaded it to and give it subproject name like ‘gameanalytics’ for example.

Using Maven repository

Add this to your repositories (inside the project build.gradle):

and add this to your dependencies (inside the app build.gradle):

Configure Android Studio

To use the SDK in Android Studio it is required to install Google Play Services from the Android SDK manager (it is listed under the ‘Extra’ folder) and make sure to add its dependencies to the app module’s build.gradle and the app’s AndroidManifest.xml. Also make sure compileSdkVersion is set to 24 in the app module’s build.gradle. Also remember to add permissions as seen in the code sample for AndroidManifest.xml (billing is only needed if IAP is used).

build.gradle (using jar)

build.gradle (using aar)

AndroidManifest.xml (only for jar)

Using Maven

In the project build.gradle file add the following to the repository section.

In the same file you should make sure the following settings are at least supporting version 24 for your app.

In the application build.gradle file add the following to the dependencies section.

Storage permissions

The SDK will use a database stored that can reach up to several MBs if the user keep being offline for longer periods of time while playing. When the user is back online it will attempt to send the events. Where the database is placed depends on permissions.


If the user’s device has Android API level 19 (Kitkat) or above, the SDK will try use context.getExternalCacheDir() (if it exists) to store its internal database.

If the device is less than Android API level 19 (Kitkat) and if READ_EXTERNAL_STORAGE and WRITE_EXTERNAL_STORAGE permissions have been added the SDK will also try to use context.getExternalCacheDir().

If the none of the previous mentioned conditions have been met, then context.getCacheDir() will be used for storage of the internal database.

Orientation change configuration

If your game can change orientation then each time the orientation changes it will cause the activity to destroy and be recreated. This will create a new session in the SDK. To avoid this it is very important to add the following line along with your activity entry in the AndroidManifest.xml file

Here is an example of an activity entry inside the AndroidManifest.xml

Optional fallback option for identifier (IMEI)

You have the option to enable IMEI as a fallback option for device identifier if you know some of your users’ device don’t have Google AID or Android ID available (which is used as device identifiers). This is most relevant for some Chinese devices, but this option requires you to add the following permission to the manifest file:

Note since Android v6.0+ this permission has been marked as dangerous and therefore on these devices it is required to explicit ask the user for his or her permission via pop-up dialogue which will be shown once for the user to allow or deny the required permission.

Remember to add this to your activity class if you haven’t handled the permission pop-up response before the SDK pops its own permission window up:

Now you are ready to write some code!


Using the SDK

Now we should be ready for adding code to activate the SDK!

  1. configuration
  2. initialization
  3. adding events or changing dimensions

The configuration and initialization steps should be called inside the onCreate method of the Activity (e.g. class which is created first in the app.

Once step 1 & 2 is done you can add events at different parts of the game code where some relevant action is happening.

Remember to import the GameAnalytics package whenever you need to call the SDK.


The configuration phase happens before initialization is called. The available configuration options are listed here.

  • build
  • available (allowed) custom dimensions
  • available (allowed) resource currencies
  • available (allowed) resource item types


Build is used to specify the current version of your game. Specify it using a string. Recommended to use a 3 digit version like [major].[minor].[patch]

User id

The SDK will automatically generate a user id and this is perfectly fine for almost all cases. Sometimes it is useful to supply this user_id manually – for example if you download raw data for processing and need to match your internal user id (could be a database index on your user table) to the data collected through GameAnalytics.

Note that if you introduce this into a game that is already deployed (using the automatic id) it will start counting existing users as new users and your metrics will be affected. Use this from the start of the app lifetime.

Specifying allowed values

For certain types it is required to define a whitelist containing possible unique values during the configuration phase. When the SDK is being used (after initialization) only the specified values will be allowed. 20 values are allowed for each list.

Processing many unique dimension values can be taxing for our servers. A few games with a poor implementation can seriously increase our cost and affect stability. Games will be blocked if they submit too many unique dimension values. We have this configuration requirement to guide users into planning what dimension values can be used.

Each resource currency string should only contain [A-Za-z] characters.


To initialize the SDK you have two options.

With activity

Since version 2.1.0 of the SDK we recommend that you call this function to initialize, using the apps main activity, and the game key and game secret for your game.

Without activity calling it separately

Alternatively you can use this function to initialize the SDK, using the game key and game secret for your game.

Using this approach you MUST call the following function inside your Activity class in the onCreate method, before calling any of the configuration functions and before calling initializeWithGameKey or any other GameAnalytics function:

Don’t have any keys yet?
Head over here and register your game at the GameAnalytics website!


Once initialize is called it will start the first session and automatically handle session changes based on activity events. Read more about sessions here including manual session handling.


Below is a common example of the code placed in the main activity class.



GameAnalytics feature the following event types.

Event Description
Business In-App Purchases supporting receipt validation on GA servers.
Resource Managing the flow of virtual currencies – like gems or lives.
Progression Level attempts with Start, Fail & Complete event.
Error Submit exception stack traces or custom error messages.
Design Submit custom event id’s. Useful for tracking metrics specifically needed for your game.

Event id’s are strings separated by colons defining an event hierarchy – like “kill:robot:large”.

It is important to not generate an excessive amount of unique nodes possible in the event hierarchy tree.

A bad implementation example. [level_name]:[weapon_used]:[damage_done]

level_name could be 100 values, weapon_used could be 300 values and damage_done could be 1-5000 perhaps. This will generate an event hierarchy with:

100 * 300 * 5000 = 150M possible nodes.

This is far too many. Also the damage should be put as a value and not in the event string. The processing will perhaps be blocked for a game doing this and cause other problems when browsing our tool.

The maximum amount of unique nodes generated should be around 10k.

Please read our event guide here. You will get the most benefit of GameAnalytics when understanding what and how to track.


Business events are used to track (and validate) real-money transactions.

Many games are hacked and distributed illegally. Hacking an app will often involve faking/simulating all purchase requests. This will result in several Business events being sent to GameAnalytics for transactions that never occurred. GameAnalytics provide the option of receipt validation for each purchase sent to GA servers. This process can ensure that revenue metrics reflect the actual spending in your game.

Some configuration is needed before receipt validation will be active.
Read information about validation and requirements for different platforms here.

Business event with receipt

When submitting a Business Event supply the following from the IAP procedure.

  • signature (INAPP_DATA_SIGNATURE)

Read more about retrieving these needed fields at the Google documentation here.

Add a business event when an in-app purchase is completed.

Field Type Description Example
currency string Currency code in ISO 4217 format. USD
amount integer Amount in cents. 99 is 0.99$
itemType string The type / category of the item. GoldPacks
itemId string Specific item bought. 1000GoldPack
cartType string The game location of the purchase.
Max 10 unique values.
receipt base64 string The transaction receipt. Null allowed. null
store string App store used. Can only be google_play at the moment. google_play
signature base64 string The transaction receipt signature. Null allowed. null

If the receipt/signature is null (or is an invalid receipt) then it will be submitted to the GA server but will register as not validated.

Receipt json schema

Example: Correct receipt information

It is possible to use code frameworks that handle IAP flow and of course every is done a bit differently This code example uses the sample code included in Android SDK found under this directory:

First of all the SkuDetails class has been modified slightly in this example to expose all information needed:

The above example assumes you have setup onIabPurchaseFinished and onQueryInventoryFinished to called on the correct events.

Price (cents) and the currency ISO 4217 format

The amount is an integer with the price cent value. Also the currency has to conform to the ISO 4217 format. Make sure the price is in cents and that the currency strings are returned as required.

For more information regarding business events go here.


Resource events are used to register the flow of your in-game economy (virtual currencies) – the sink (subtract) and the source (add) for each virtual currency.

Before calling the resource event it is needed to specify what discrete values can be used for currencies and item types in the Configuration phase.

source (add) Gem currency from an in-app purchase.

sink (subtract) Gem currency to buy an item.

sink (subtract) Gem currency to source (buy) some amount of another virtual currency (BeamBooster).

sink (subtract) 3 BeamBooster currency that were used during a level.

Field Type Description Example
flowType enum A defined enum for sourcing and sinking resources. GAResourceFlowType.Sink
currency string The resource type/currency to track. Has to be one of the configured available resource currencies.
This string can only contain [A-Za-z] characters.
Gems, BeamBoosters, Coins
amount float Amount sourced or sinked. 0 or negative numbers are not allowed. 100.0
itemType string For sink events it can describe an item category you are buying (Weapons) or a place (Gameplay) the currency was consumed. For source events it can describe how the currency was gained. For example “IAP” (for in-app purchase) or from using another currency (Gems). Has to be one of the configured available itemTypes. Weapons, IAP, Gameplay, Boosters
itemId string For sink events it can describe the specific item (SwordOfFire) gained. If consumed during Gameplay you can simply use “Consumed”. For source events it describes how the player got the added currency. This could be buying a pack (BoosterPack5) or earned through Gameplay when completing a level (LevelEnd). BoosterPack5, SwordOfFire, LevelEnd, Coins400

Be careful to not call the resource event too often! In a game where the user collect coins fairly fast you should not call a Source event on each pickup. Instead you should count the coins and send a single Source event when the user either complete or fail the level.

For more information about the resource event go here.


Progression events are used to track attempts at completing some part of a game (level, area). A defined area follow a 3 tier hierarchy structure (could be world:stage:level) to indicate what part of the game the player is trying to complete.

When a player is starting a progression attempt a start event should be added.
When the player then finishes the attempt a fail or complete event should be added along with a score if needed.

Add a progression start event.

It is not required to use all 3 if your game does not have them.

  • progression01
  • progression01 and progression02
  • progression01 and progression02 and progression03
Field Type Description Example
progressionStatus enum Status of added progression GAProgressionStatus.Start GAProgressionStatus.Fail GAProgressionStatus.Complete
progression01 string Required progression location. World01
progression02 string Not required. Use if needed. Stage01
progression03 string Not required. Use if needed. Level01
score integer An optional score when a user completes or fails a progression attempt. 1023

For more information on the progression event go here.


Used to track custom error events in the game. You can group the events by severity level and attach a message.

To add a custom error event call the following function:

Field Type Description Example
severity enum Severity of error GAErrorSeverity.GAErrorSeverityDebug
message string Error message (can be null) “Error when entering level12”

For more information on the error event go here.


Every game is special. Therefore some needed events might not be covered by our other event types. The design event is available for you to add your own event-id hierarchy.

Please note that custom dimensions and progression filters will not be added on design and error events. Therefore you cannot (at the moment) filter by these when viewing design or error metrics.

To add a design event call the following method.

It is also possible to add a float value to the event. This will (in addition to count) make the mean and sum aggregation available in the tool.

Field Type Description Example
eventId string The eventId is a hierarchy string that can consist of 1-5 segments separated by ‘:’. Each segment can have a max length of 32. “StartGame:ClassLevel1_5”, “StartGame:ClassLevel6_10”
value float A float event tied to the eventId. Will result in sum & mean values being available. 34.5

It is important to not generate an excessive amount of unique nodes possible in the event hierarchy tree.

A bad implementation example. [level_name]:[weapon_used]:[damage_done]

level_name could be 100 values, weapon_used could be 300 values and damage_done could be 1-5000 perhaps. This will generate an event hierarchy with:

100 * 300 * 5000 = 1.5M possible nodes. This is far too many. Also the damage should be put as a value and not in the event string. The processing will perhaps be blocked for a game doing this and cause other problems when browsing our tool.

The maximum amount of unique nodes generated should be around 10k.

Please read our event guide here. You will get the most benefit of GameAnalytics when understanding what and how to track.


Using Custom Dimensions

GameAnalytics support the use of 3 custom dimensions.

  • Custom01
  • Custom02
  • Custom03

During the game it is possible to set the active value for each custom dimension dynamically. Once a dimension is set it will be persisted across sessions/game-start and automatically be added to these event categories.

  • Business
  • Resource
  • Progression

Setting each custom dimension.

To reset a set custom dimension simply set it to empty string or null:

Field Type Description Example
customDimension string One of the available dimension values set in the configuration phase. Will persist cross session. Set to null to reset. ninja

Read more about custom dimensions here.


User Information

During the game it is possible to set information about your users that will then be annotated to all other events.

  • gender
  • Facebook ID
  • birthyear (age)

These user values will persist cross session/game-launch. Set them to nil to reset.

Set gender.

Set birthyear.

Set Facebook ID.

Field Type Description Example
gender string Gender of player. female, male
birthYear integer The year the player was born. 1980
facebookId string Facebook Id of the player. 123456789012345



The SDK is designed to be as silent as possible and use very few resources. You will therefore not get much information by default in your development console.

We have 2 different debug log types that can be enabled / disabled (at any time).

  • info log
  • verbose log

Info log

Short messages will be output when enabled explaining when some action is being performed by the SDK. Sometimes cropping text / values to make it more readable.

Enable info log when implementing the SDK – remember to turn it off in production!

Verbose Log

Console output when each event is added (all fields) in JSON string format. This is the data being submitted to the GA servers for each event.

Enable verbose log when troubleshooting events.

This can result in a lot of text. When troubleshooting/debugging events it is therefore recommended to enable/disable when performing the action that need inspection.

Troubleshooting example.

Verify Implementation

Enable the Info Log to verify that events are being sent from your game project without any issues being reported.

Events submitted should register after a minor delay in our realtime dashboard in the GameAnalytics tool.

Read more about the realtime dashboard and our data processing.


Session Handling

By default the SDK will handle session start/end automatically, but it is also possible to manually control this yourself.

Be aware that the initialization will always automatically start the first session even with manual session handling.

If you are using ads in your game there is a big possibility that the onPause() and onStop() events will be triggered when the ads are showing which will interfere with the session length for information on how to fix this to look here

Automatic session handling

The automatic session handling will track the focused time the user is spending in your game – from game launch to the user leaving the game.

session start

On Android a new session will start once the game is launched or when the app is resuming if there is no current session.

session end

A session will end once the game is going to homescreen (or is not visible anymore).

It will end the session at once if the application received the onStop event from the game activity. It can also end the session if onPause event was received and 90 seconds have passed (sometimes only the onPause will trigger even though the user left the app).

Manual session handling

The automatic session handling only works if the game is contained in one activity.

It will then handle session end and start based on the events on that single activity. This behavior is common (having one activity) but some games define multiple activities and this automatic session handling will not work in an optimal way.

If your game does have multiple activities (or you just want to be in control when to start and end sessions) you can enable/disable manual session handling by calling this at any given time:

You will then need to call endSession and startSession at the appropriate times.

With manual session handling it is recommended to also call endSession when the game activity event onStop is fired. This will ensure a correct session close when users click the home or on/off button.


This will end a session if:

  • manual session handling is enabled
  • a session is active
  • SDK is initialized (initialize will start a session automatically)


This will start a new session if:

  • manual session handling is enabled
  • SDK is initialized (initialize will start a session automatically)

If a current session is active then it will end the current session and start a new one.

Handling ads and preserve correct session length

Ads will most likely trigger onPause() and onStop() which will interfere with the session length of the game. To prevent this you need to use manual session handling at least when you are about to show ads. Here is an example using AdColony but it should easily apply to ad SDKs with the own events surrounding the ad (on showing and on finished ad):

If you are already using manual session handling from the beginning of your game then you don’t need to worry about this.

Behind the scenes

This is what happens when the session is starting or ending.

Session start

  1. Generate new session.
  2. Add a session start event (a “user” event).
  3. Start the periodic activation of submitting queued events.
  4. Next event submit will fix potential missing session_end from earlier sessions.

Session end

  1. Stop the periodic activation of submitting queued events.
  2. Add a session_end event.
  3. Submit queued events.

Event Queue

Whenever an event is added (and validated) it will be added to a local database queue.


Every 8 seconds the SDK will start a task for submitting queued events since last submit. This processing is done in a separate low-priority thread that will have minimum impact on performance. The payload is gzipped and will therefore only consume a small amount of bandwidth.


When a device is offline the events are still added to the queue. When the device is online it will submit.

Thread Handling

For the Android platform almost every piece of this code is run using a dedicated low-priority serial thread queue to avoid UI lag or sudden performance spikes. The queue will execute each task sequentially. If the SDK add several tasks to the queue then each will be executed in turn. A task could be adding an event or submitting all queued events.

Consider this example with 3 calls.

The configureBuild is required to be called before initialize is completely finished. The design event call is required after initialize is finished. The queuing will make sure that each task is completely finished before proceeding to the next one.

There is more!

There is much more to GameAnalytics and we suggest that you read our general documentation.

Please create a support ticket if you have any feedback like..

  • bugs
  • confusing features or UI
  • great ideas!

We hope you enjoy our service!