Android SDK
We have built an official Android SDK that uses our API’s common methods, and some specific to the Android platform.
Releases
https://github.com/kissmetrics/KISSmetrics-Android-SDK/releases
Setup
- Within your Application subclass or main activity’s onCreate method:
Initializing with Development and Production keys
Example Calls
Optional Automated Tracking
autoRecordInstalls()
Calling this records two events:
- 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
Changes from v1
If you previously used 80steve’s Android library, there are some functional changes from his library:
- Identities, Events and Properties are URL encoded for you. If you’re upgrading to this SDK, you should remove any URL encoding or URL encoded characters that may have been added as a workaround to the lack of encoding in the unoffical Android SDK.
- The
identify
method now works the same as it does in our JavaScript library. That is, recording identities no longer aliases known identities to one another.- For example, if a user has been given a known identity such as “user@example.com” and a second call is made to identify: “another@example.com”, the SDK no longer assumes that this a second known identity for the same user and these identities will no longer be aliased to one another automatically.
- Now, if there are 2 or more known identities of a user, a call to
alias
these two identities must be made. - Previously, a call to
clearIdentity()
was required before a new users’s identity was set. Though, it’s still a good idea to callclearIdentity()
when a user signs out.
Performance
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.
Android v2 SDK specs
- 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)