The Android Tracker has evolved in tandem with the Java Tracker. We have based the Android Tracker on the same Java Tracker Core that powers the Java Tracker, along with a few additions, such as tracking geographical location, and sending mobile-specific context data.
So you’ll see many similarities between the two Trackers, which I’ll explain in further detail in the rest of the post:
- How to install the tracker
- How to use the tracker
- Mobile context
- Location context
- Under the hood
- Getting help
The Android Tracker has been built and tested with the Android SDK version 19, but is compatible with SDK version 11 and above. This means that the tracker is compatible with majority of the Android devices currently being used.
The release version of this tracker (0.1.1) is available within Snowplow’s Maven repository. We have instructions for installing the tracker for Maven, Gradle and SBT in the Android Tracker Setup guide.
Here is the Gradle setup for example:
To send the events, you need to update your
AndroidManifest.xml with the internet access permission:
Using the tracker requires you to import the Tracker module like so:
We need to create an
Emitter to send events created by the
Emitter instance requires an Android
Context instance as well for caching, which we explain more about later in this post. For now, here is an example of how the
Tracker are created:
Now let’s send in a couple of events:
Check out the Android Tracker documentation on the wiki for the tracker’s full API.
If you create a
Subject instance, it will attach as much contextual information as it can, including by default the operating system version, device model and manufacturer.
If you construct the
Subject with an Android
Context, the Tracker will attach additional context about the user’s device, such as screen resolution, carrier information and most importantly, the Advertising ID. The Advertising ID requires the Play Services SDK to be set-up which you can find in more detail at the Android Tracker Setup guide.
Here an example of how this would look:
The mobile-specific context is added to each event’s context array structured using the mobile context schema.
If you’re using Redshift, you would need to install the mobile_context table using this script.
Subject class also lets you attach location-based contextual information to your events. To grab the location information you need to add the following permissons to your
Geolocation context requires you to pass an Android
Context to the Subject class. The location information will then be added as part of the context array, structured using the geolocation context schema.
If you’re using Redshift, you would need to install the geolocation_context table using this script.
The Android Tracker uses an SQLite database to store events, saving them until they have been successfully sent to a collector (i.e. a 200 HTTP response is received back from the request sent). This is the main reason we requre an Android Context to be passed to the Emitter.
All requests made, either GET or POST, are sent using an
AsyncTask class. This lets us send events using a background thread. Note that we have removed the option to send requests synchronously, which the Java Tracker can do, to avoid blocking calls on the main UI thread.
This is only our first release of the Android Tracker and we look forward to further releases based on your real-world usage of the tracker.