Android
We have built an official Android SDK that uses our API’s common methods, and some specific to the Android platform.
Last updated
We have built an official Android SDK that uses our API’s common methods, and some specific to the Android platform.
Last updated
Within your game subclass or main activity's onCreate
method:
Initializing with Development and Production Keys
Installed App
Updated App
autoSetAppProperties()
- Calling this sets the following properties:
App Version : 1.0.0 (aka: versionName)
App Build : 1 (aka: versionCode)
autoSetHardwareProperties()
- Calling this sets the following properties:
Device Manufacturer : asus
Device Model: Nexus 7 (but this may also just be a cryptic model #. This depends on the manufacturer.)
System Name : Android (hard-coded)
System Version : 4.2.2
autoRecordInstalls()
- Calling this records two events:
In the new SDK, all calls to record events, properties, identities and aliases are immediately passed onto a background thread for processing and delivery.
In our unofficial SDK (v1), the processing of these calls was handled by the same thread that made the call to record before being delivered asynchronously. This wasn’t optimal as an application’s main thread is responsible for view updates and user interactions.
As a third party addition to our customers’ apps, we should use as little of the main thread as possible to ensure that our SDK doesn’t contribute to any lag in the users’ experience of their apps.
Size (compiled): 41kb
Memory Overhead
idle: 21kb
per avg. event with properties: estimated at < 500 bytes (< 200 for required params plus assumed < 300 bytes for average event with properties). During archiving of each event with properties, approximately 6kb of memory is allocated.
Android version support: 2.2 (Froyo) (>99% of Android devices)