Skill 82 · Instrument Product Analytics
Subchapter 82.1
references/android.mdMarkdown31 KBView on GitHub
AI agents: this is one page from PostHog’s docs. Full index of Markdown docs for LLMs: https://posthog.com/llms.txt (opens in a new tab)
It uses an internal queue to make calls fast and non-blocking. It also batches requests and flushes asynchronously, making it perfect to use in any part of your mobile app.
The best way to install the PostHog Android library is with a build system like Gradle (opens in a new tab). This ensures you can easily upgrade to the latest versions.
All you need to do is add the posthog-android module to your App’s build.gradle or build.gradle.kts:
dependencies {
implementation 'com.posthog:posthog-android:3.+'
}dependencies {
implementation("com.posthog:posthog-android:3.+")
}The best place to initialize the client is in your Application subclass.
Kotlin
import android.app.Application
import com.posthog.android.PostHogAndroid
import com.posthog.android.PostHogAndroidConfig
class SampleApp : Application() {
companion object {
const val POSTHOG_API_KEY = "<ph_project_token>"
// usually 'https://us.i.posthog.com' or 'https://eu.i.posthog.com'
const val POSTHOG_HOST = "https://us.i.posthog.com"
}
override fun onCreate() {
super.onCreate()
val config = PostHogAndroidConfig(
apiKey = POSTHOG_API_KEY,
host = POSTHOG_HOST
)
PostHogAndroid.setup(this, config)
}
}You can send custom events using capture:
Kotlin
import com.posthog.PostHog
PostHog.capture(event = "user_signed_up")Tip: We recommend using a
[object] [verb]format for your event names, where[object]is the entity that the behavior relates to, and[verb]is the behavior itself. For example,project created,user signed up, orinvite sent.
Optionally, you can include additional information with the event by including a properties (opens in a new tab) object:
Kotlin
import com.posthog.PostHog
PostHog.capture(
event = "user_signed_up",
properties = mapOf(
"login_type" to "email",
"is_free_trial" to true
)
)PostHog autocapture automatically tracks the following events for you:
android.app.Activity)With captureScreenViews = true (opens in a new tab), PostHog will try to record all screen changes automatically.
The screenTitle will be the <activity> (opens in a new tab)‘s android:label, if not set it’ll fallback to the <application> (opens in a new tab)‘s android:label or the <activity> (opens in a new tab)‘s android:name.
XML
<activity
android:name="com.example.app.ChildActivity"
android:label="@string/title_child_activity"
...
</activity>If you want to manually send a new screen capture event, use the screen function.
This function requires a screenTitle. You may also pass in an optional properties object.
Kotlin
import com.posthog.PostHog
PostHog.screen(
screenTitle = "Dashboard",
properties = mapOf(
"background" to "blue",
"hero" to "superhog"
)
)We highly recommend reading our section on Identifying users (opens in a new tab) to better understand how to correctly use this method.
Using identify, you can associate events with specific users. This enables you to gain full insights as to how they’re using your product across different sessions, devices, and platforms.
An identify call has the following arguments:
userProperties. See the difference between userProperties and userPropertiesSetOnce (opens in a new tab)Kotlin
import com.posthog.PostHog
PostHog.identify(
distinctId = distinctID,
userProperties = mapOf(
"name" to "Max Hedgehog",
"email" to "max@hedgehogmail.com"
),
userPropertiesSetOnce = mapOf(
"date_of_first_log_in" to "2024-03-01"
),
)You should call identify as soon as you’re able to. Typically, this is after your user logs in. This ensures that events sent during your user’s sessions are correctly associated with them.
When you call identify, all previously tracked anonymous events will be linked to the user.
You may find it helpful to get the current user’s distinct ID. For example, to check whether you’ve already called identify for a user or not.
To do this, call distinctId(). This returns either the ID automatically generated by PostHog or the ID that has been passed by a call to identify().
Use tracingHeaders to connect Android network requests to backend events, errors, and LLM traces captured by a server-side PostHog SDK. Tracing headers are added by the PostHogOkHttpInterceptor, so install the interceptor on each OkHttpClient whose requests should include PostHog context.
Kotlin
import com.posthog.PostHogOkHttpInterceptor
import com.posthog.android.PostHogAndroid
import com.posthog.android.PostHogAndroidConfig
import okhttp3.OkHttpClient
val config = PostHogAndroidConfig(
apiKey = POSTHOG_API_KEY,
host = POSTHOG_HOST,
).apply {
tracingHeaders = listOf("api.example.com")
}
PostHogAndroid.setup(this, config)
val okHttpClient = OkHttpClient.Builder()
.addInterceptor(PostHogOkHttpInterceptor())
.build()Hostnames are matched exactly and should not include protocols, paths, ports, or wildcard subdomains. Matching OkHttp requests include X-POSTHOG-DISTINCT-ID and X-POSTHOG-SESSION-ID when those values are available.
Sometimes, you want to assign multiple distinct IDs to a single user. This is helpful when your primary distinct ID is inaccessible. For example, if a distinct ID used on the frontend is not available in your backend.
In this case, you can use alias to assign another distinct ID to the same user.
Kotlin
/**
* Create an alias for the current user.
*/
PostHog.alias("distinct_id")We strongly recommend reading our docs on alias (opens in a new tab) to best understand how to correctly use this method.
PostHog captures two types of events: anonymous and identified (opens in a new tab)
Identified events enable you to attribute events to specific users, and attach person properties (opens in a new tab). They’re best suited for logged-in users.
Scenarios where you want to capture identified events are:
Anonymous events are events without individually identifiable data. They’re best suited for web analytics (opens in a new tab) or apps where users aren’t logged in.
Scenarios where you want to capture anonymous events are:
Under the hood, the key difference between identified and anonymous events is that for identified events we create a person profile (opens in a new tab) for the user, whereas for anonymous events we do not.
Important: Due to the reduced cost of processing them, anonymous events can be up to 4x cheaper than identified ones, so we recommended you only capture identified events when needed.
The Android SDK captures anonymous events by default. However, this may change depending on your personProfiles config (opens in a new tab) when initializing PostHog:
personProfiles = PersonProfiles.IDENTIFIED_ONLY (recommended) (default) - Anonymous events are captured by default. PostHog only captures identified events for users where person profiles (opens in a new tab) have already been created.
personProfiles = PersonProfiles.ALWAYS - Capture identified events for all events.
personProfiles = PersonProfiles.NEVER - Capture anonymous events for all events.
For example:
Kotlin
val config = PostHogAndroidConfig(
apiKey = POSTHOG_API_KEY,
host = POSTHOG_HOST,
).apply {
personProfiles = PersonProfiles.IDENTIFIED_ONLY
}If you’ve set the personProfiles config (opens in a new tab) to IDENTIFIED_ONLY (the default option), anonymous events are captured by default. Then, to capture identified events, call any of the following functions:
When you call any of these functions, it creates a person profile (opens in a new tab) for the user. Once this profile is created, all subsequent events for this user will be captured as identified events.
Alternatively, you can set personProfiles to ALWAYS to capture identified events by default.
To set properties (opens in a new tab) on your users via an event, you can leverage the event properties userProperties and userPropertiesSetOnce.
When capturing an event, you can pass a property called userProperties as an event property, and specify its value to be an object with properties to be set on the user that will be associated with the user who triggered the event.
Kotlin
import com.posthog.PostHog
PostHog.capture(
event = "button_b_clicked",
properties = mapOf("color" to "blue"),
userProperties = mapOf(
"string" to "value1",
"integer" to 2
)
)userPropertiesSetOnce works just like userProperties, except that it will only set the property if the user doesn’t already have that property set.
Kotlin
import com.posthog.PostHog
PostHog.capture(
event = "button_b_clicked",
properties = mapOf("color" to "blue"),
userPropertiesSetOnce = mapOf(
"string" to "value1",
"integer" to 2
)
)Super Properties are properties associated with events that are set once and then sent with every capture call, be it a $screen, or anything else.
They are set using PostHog.register, which takes a key and value, and they persist across sessions.
For example, take a look at the following call:
Kotlin
import com.posthog.PostHog
PostHog.register("team_id", 22)The call above ensures that every event sent by the user will include "team_id": 22. This way, if you filtered events by property using team_id = 22, it would display all events captured on that user after the PostHog.register call, since they all include the specified Super Property.
However, please note that this does not store properties against the User, only against their events. To store properties against the User object, you should use PostHog.identify. More information on this can be found on the Sending User Information section.
Super Properties are persisted across sessions so you have to explicitly remove them if they are no longer relevant. In order to stop sending a Super Property with events, you can use PostHog.unregister, like so:
Kotlin
import com.posthog.PostHog
PostHog.unregister("team_id")This will remove the Super Property and subsequent events will not include it.
If you are doing this as part of a user logging out you can instead simply use PostHog.reset which takes care of clearing all stored Super Properties and more.
You can completely opt-out users from data capture. To do this, there are two options:
optOut to true in your PostHog config:Kotlin
val config = PostHogAndroidConfig(
apiKey = "<ph_project_token>",
host = "https://us.i.posthog.com"
)
config.optOut = true
PostHogAndroid.setup(this, config)optOut():Kotlin
PostHog.optOut()Similarly, you can opt users in:
Kotlin
PostHog.optIn()To check if a user is opted out:
Kotlin
PostHog.isOptOut()You can configure how many events queue before flushing with flushAt. Setting this to 1 will send events immediately and will use more battery. The default is 20.
You can also configure the flush interval with flushIntervalSeconds (default 30), after which queued events are sent regardless of how many have been gathered:
Kotlin
import com.posthog.android.PostHogAndroidConfig
val config = PostHogAndroidConfig(apiKey = POSTHOG_API_KEY, host = POSTHOG_HOST).apply {
flushAt = 20
flushIntervalSeconds = 30
}You can also manually flush the queue to start sending events immediately instead of waiting for the next batch:
Kotlin
import com.posthog.PostHog
PostHog.flush()Flushing is best-effort and asynchronous – it starts sending queued events in the background but doesn’t wait for the request to finish, so it isn’t a delivery guarantee.
To reset the user’s ID and anonymous ID, call reset. Usually you would do this right after the user logs out.
Kotlin
import com.posthog.PostHog
PostHog.reset()PostHog’s feature flags (opens in a new tab) enable you to safely deploy and roll back new features as well as target specific users and groups with them.
Kotlin
import com.posthog.PostHog
val result = PostHog.getFeatureFlagResult("flag-key")
if (result?.enabled == true) {
// Do something differently for this user
// Optional: fetch the payload from the same evaluation result
val matchedFlagPayload = result.payload
}Kotlin
import com.posthog.PostHog
val result = PostHog.getFeatureFlagResult("flag-key")
if (result?.variant == "variant-key") { // replace "variant-key" with the key of your variant
// Do something differently for this user
// Optional: fetch the payload from the same evaluation result
val matchedFlagPayload = result.payload
}You can inspect all currently loaded feature flags with PostHog.getAllFeatureFlags(). It returns each flag’s key, enabled state, variant, and payload, and does not send a $feature_flag_called event, so calling it won’t affect your experiment results or flag usage analytics:
Kotlin
import com.posthog.PostHog
PostHog.getAllFeatureFlags()?.forEach { flag ->
println("${flag.key} ${flag.enabled} ${flag.variant} ${flag.payload}")
}Every time a user opens the app, we send a request in the background to fetch the feature flags that apply to that user. We store those flags in the storage.
This means that for most screens, the feature flags are available immediately – except for the first time a user visits.
To handle this, you can use the onFeatureFlags callback to wait for the feature flag request to finish:
Kotlin
import com.posthog.PostHog
import com.posthog.android.PostHogAndroidConfig
import com.posthog.PostHogOnFeatureFlags
// During SDK initialization
val config = PostHogAndroidConfig(apiKey = "<ph_project_token>").apply {
onFeatureFlags = PostHogOnFeatureFlags {
if (PostHog.isFeatureEnabled("flag-key")) {
// do something
}
}
}
// And/or after the SDK is initialized
PostHog.reloadFeatureFlags {
if (PostHog.isFeatureEnabled("flag-key")) {
// do something
}
}Feature flag values are cached. If something has changed with your user and you’d like to refetch their flag values, call:
Kotlin
import com.posthog.PostHog
PostHog.reloadFeatureFlags()To track when someone sees or interacts with a feature, use captureFeatureView and captureFeatureInteraction.
Kotlin
import com.posthog.PostHog
PostHog.captureFeatureView("flag-key", flagVariant = "variant-key")
PostHog.captureFeatureInteraction("flag-key", flagVariant = "variant-key")Since there is a delay between initializing PostHog and fetching feature flags, feature flags are not always available immediately. This makes them unusable if you want to do something like redirecting a user to a different page based on a feature flag.
To have your feature flags available immediately, you can initialize PostHog with precomputed values until it has had a chance to fetch them. This is called bootstrapping. After the SDK fetches feature flags from PostHog, it will use those flag values instead of bootstrapped ones.
Set config.bootstrap before calling setup() to seed identity and flag values before the first /flags response (requires Android SDK 3.55.0+):
Kotlin
import com.posthog.PostHogBootstrapConfig
val config = PostHogAndroidConfig(apiKey = POSTHOG_API_KEY, host = POSTHOG_HOST)
config.bootstrap = PostHogBootstrapConfig(
distinctId = "distinct_id_of_your_user",
isIdentifiedId = true,
featureFlags = mapOf(
"flag-1" to true,
"variant-flag" to "control"
)
)
PostHogAndroid.setup(this, config)setup() means events captured synchronously during initialization (like Application Installed) carry your distinct ID instead of the SDK-generated UUID.
isIdentifiedId: false, the default) seeds the anonymous ID only when none is persisted yet. Once an anonymous ID exists on disk, or the person has been identified, the SDK ignores it.isIdentifiedId: true) is for a signed-in identity available to your app (for example, from a backend session token). On a fresh install, it seeds the distinct ID, marks the person identified, and generates a separate device ID. On a returning install, a matching anonymous ID is marked identified without emitting $identify; a different anonymous ID is merged via identify() when person profiles are enabled. This emits $identify unless capturing is opted out. A different, already-identified person is left untouched./flags response, then replaced. A complete /flags response takes over entirely, so bootstrapped-only keys don’t persist past it. Only enabled flags are seeded: a true boolean or a non-empty variant string. A false or empty value is dropped, matching posthog-js. Seed payloads with the separate featureFlagPayloads option. Flag values and payloads must be JSON-serializable, or they’re dropped. Bootstrapped flags are cleared on reset().The feature-flags-loaded signal fires as soon as bootstrapped flags are applied, so startup logic can read them immediately. These SDKs don’t support the sessionID bootstrap option. When person profiles are set to never, the SDK preserves a different anonymous identity instead of merging it into an identified bootstrap.
See the SDK bootstrapping guide (opens in a new tab) for the cross-SDK overview.
Since experiments (opens in a new tab) use feature flags, the code for running an experiment is very similar to the feature flags code:
Kotlin
import com.posthog.PostHog
if (PostHog.getFeatureFlag("experiment-feature-flag-key") == "variant-name") {
// do something
}It’s also possible to run experiments without using feature flags (opens in a new tab).
Group analytics allows you to associate the events for that person’s session with a group (e.g. teams, organizations, etc.). Read the Group Analytics (opens in a new tab) guide for more information.
Note: This is a paid feature and is not available on the open-source or free cloud plan. Learn more on the pricing page (opens in a new tab).
Kotlin
import com.posthog.PostHog
// organization is the group type, company_id_in_your_db is the group ID
PostHog.group(
type = "company",
key = "company_id_in_your_db"
)Kotlin
import com.posthog.PostHog
PostHog.group(
type = "company",
key = "company_id_in_your_db",
groupProperties = mapOf("name" to "Awesome Inc.")
)The name is a special property which is used in the PostHog UI for the name of the group. If you don’t specify a name property, the group ID will be used instead.
To set up error tracking in your project, see the error tracking docs (opens in a new tab).
To set up logs (opens in a new tab) in your Android app, follow the Android logs installation guide (opens in a new tab). The SDK exposes PostHog.logger.{trace,debug,info,warn,error,fatal} for sending structured records to PostHog Logs, with batching, offline persistence, and a rate cap built in.
Minimum version:
com.posthog:posthog-android@3.46.0or later.
To set up session replay (opens in a new tab) in your project, all you need to do is install the Android SDK, enable “Record user sessions” in your project settings (opens in a new tab) and enable the sessionReplay option.
To set up surveys, follow the additional installation instructions for Android (opens in a new tab). Surveys launched with popover presentation (opens in a new tab) are automatically shown to users matching the display conditions (opens in a new tab) you set up.
The PostHog Android SDK will continue to capture events when the device is offline. The events are stored in a queue in the device’s file storage and are flushed when the device is online.
maxQueueSize in the configuration.flush() while the device is offline, it aborts early and the events are not flushed.If you’re not seeing the expected events being captured, the feature flags being evaluated, surveys being shown, or session replay/error tracking behavior, you can enable debug mode to see what’s happening.
You can enable debug mode by setting the debug option to true in the PostHogAndroidConfig object. This will enable verbose logs about the inner workings of the SDK.
Kotlin
val config = PostHogAndroidConfig(apiKey = POSTHOG_API_KEY, host = POSTHOG_HOST).apply {
debug = true
// ... other config options
}When creating the PostHog client, pass a PostHogAndroidConfig. It inherits the core PostHogConfig options and adds Android-specific options.
Kotlin
import com.posthog.PersonProfiles
import com.posthog.android.PostHogAndroidConfig
val config = PostHogAndroidConfig(
apiKey = POSTHOG_API_KEY,
host = POSTHOG_HOST
).apply {
captureApplicationLifecycleEvents = true
captureScreenViews = true
captureDeepLinks = true
flushAt = 20
maxQueueSize = 1000
maxBatchSize = 50
maxRetries = 3
flushIntervalSeconds = 30
debug = false
optOut = false
sendFeatureFlagEvent = true
featureFlagCalledCacheSize = 1000
preloadFeatureFlags = true
evaluationContexts = listOf("production", "android", "mobile")
setDefaultPersonProperties = true
personProfiles = PersonProfiles.IDENTIFIED_ONLY
reuseAnonymousId = false
sessionReplay = false
errorTrackingConfig.autoCapture = false
}| Option | Default | Description |
|---|---|---|
captureApplicationLifecycleEvents | true | Captures Application Installed, Application Updated, Application Opened, and Application Backgrounded. |
captureScreenViews | true | Captures $screen for foreground android.app.Activity screens. |
captureDeepLinks | true | Captures Deep Link Opened with URL/query/referrer properties. |
| Option | Default | Description |
|---|---|---|
debug | false | Enables verbose SDK logs in Logcat. You can also call PostHog.debug(true). |
optOut | false | Prevents data capture when enabled. You can also call PostHog.optOut() and PostHog.optIn(). |
flushAt | 20 | Number of queued events that triggers a flush. |
maxQueueSize | 1000 | Maximum number of events kept across memory and disk before FIFO eviction. |
maxBatchSize | 50 | Maximum number of events sent in one batch request. |
maxRetries | 3 | Maximum retry attempts for failed requests. |
flushIntervalSeconds | 30 | Maximum delay before queued data is flushed. |
encryption | null | Optional PostHogEncryption implementation for encrypting persisted queued events. |
proxy | null | Optional java.net.Proxy for PostHog API requests. |
getAnonymousId | generated UUID | Optional hook to customize anonymous ID generation. |
reuseAnonymousId | false | Reuses one anonymous ID across user changes on the same device. |
personProfiles | PersonProfiles.IDENTIFIED_ONLY | Controls when person profiles are processed: IDENTIFIED_ONLY, ALWAYS, or NEVER. |
setDefaultPersonProperties | true | Includes default device and app properties in feature flag evaluation requests. |
releaseIdentifier | app/version fallback | Release identifier used by error tracking and uploaded ProGuard/R8 mappings. The Android Gradle plugin can inject this automatically. |
tracingHeaders | null | Exact hostnames that should receive PostHog tracing headers when using PostHogOkHttpInterceptor. |
| Option | Default | Description |
|---|---|---|
sendFeatureFlagEvent | true | Sends $feature_flag_called when a feature flag is evaluated. |
featureFlagCalledCacheSize | 1000 | Number of feature flag calls cached for deduplicating $feature_flag_called events. |
preloadFeatureFlags | true | Fetches feature flags automatically during setup. |
evaluationContexts | null | Context tags that constrain which feature flags are evaluated. Available in version 3.29.1+. The legacy evaluationEnvironments option is available in version 3.24.0+. |
onFeatureFlags | null | Callback invoked when feature flags are loaded. |
| Option | Default | Description |
|---|---|---|
sessionReplay | false | Enables session replay when project settings also allow recording. |
sessionReplayConfig | PostHogSessionReplayConfig() | Configures masking, screenshots, Logcat capture, sampling, and custom drawable conversion. |
logs | PostHogLogsConfig() | Configures Android logs (opens in a new tab). |
errorTrackingConfig | PostHogErrorTrackingConfig() | Configures error tracking. autoCapture defaults to false; set it to true to autocapture uncaught exceptions when project settings also enable error tracking. |
surveys | false | Internal/experimental native Android survey support. Native Android survey UI is not fully supported or documented yet. |
surveysConfig | PostHogSurveysConfig() | Internal/experimental survey display delegate configuration, primarily for hybrid SDKs. |
bootstrap | null | Seeds identity (distinctId, isIdentifiedId) and feature-flag state (featureFlags, featureFlagPayloads) before the first /flags response. Bootstrapped identity applies to the first session; only enabled flags are served, until the first /flags response replaces them. See SDK bootstrapping (opens in a new tab). |
Use addBeforeSend to redact, modify, or drop events before they are queued. Return null to drop an event.
Kotlin
config.addBeforeSend { event ->
event.properties?.remove("password")
if (event.event == "internal_debug_event") {
null
} else {
event
}
}You can stop specific screens from being autocaptured by filtering them in your before-send hook. Return null for any $screen event whose $screen_name matches a screen you don’t want to track, and it’s dropped before being sent – keeping unwanted screen views out of your event log.
Because it’s just a function, you can filter however you like – an ignorelist (drop the screens you name), an allowlist (invert the check to capture only the screens you name), or any custom rule such as a name prefix, a regex, or a check against the event’s properties.
Kotlin
val ignoredScreens = setOf("Splash", "Debug")
config.addBeforeSend { event ->
val screenName = event.properties?.get("$screen_name") as? String
if (event.event == "$screen" && screenName in ignoredScreens) {
null
} else {
event
}
}The Android SDK can register a device for Workflows (opens in a new tab) push notifications and capture when a user opens one. For setup, including automatic and manual registration, capturing opens, opting out, and identity verification, see Push notifications (opens in a new tab).
The Android SDK supports Android API 23 and newer.
Usually, no. The SDK declares android.permission.INTERNET and android.permission.ACCESS_NETWORK_STATE, and Android’s manifest merger adds them to your app. The SDK does not declare or require an Android Service.
Ask PostHog AI
HelpfulCould be better
This file
Nearby