chore(flags): prefer remote config over flags config parameter

[dmarticus]

Summary

• Remove config=true parameter from the flags endpoint URL (/flags/?v=2 instead of /flags/?v=2&config=true)
• Add timezone field to all flags requests
• Deprecate the remoteConfig config option and make it a no-op (remote config is now always loaded)

Remote config (/array/{apiKey}/config) is now the sole source for configuration data, so the flags endpoint only needs to return feature flags. This aligns the Android SDK with the direction being taken in posthog-js.

Based on PostHog/posthog-js#2895

Changes

File	Change
PostHogApi.kt	Remove config=true from flags URL
PostHogFlagsRequest.kt	Add timezone field (uses TimeZone.getDefault().id)
PostHogConfig.kt (posthog)	Deprecate remoteConfig option
PostHogConfig.kt (posthog-server)	Deprecate remoteConfig option
PostHog.kt	Always load remote config (ignore deprecated option)
Tests	Update expected URLs and add @Suppress("DEPRECATION")

Notes

This follows the same pattern as posthog-js:

• Remote config is loaded once at init
• reloadFeatureFlags() only reloads feature flags, not the full remote config
• Session replay config changes don't take effect until the next app restart

This is an acceptable tradeoff for simplicity and reduced API calls.

Test plan

• CI passes
• Feature flags still load correctly via remote config flow

[github-actions]

posthog-android Compliance Report

Date: 2026-02-18 12:06:50 UTC
Duration: 147040ms

⚠️ Some Tests Failed

17/29 tests passed, 12 failed

---

Capture Tests

⚠️ 17/29 tests passed, 12 failed

View Details

Test	Status	Duration
Format Validation.Event Has Required Fields	✅	2322ms
Format Validation.Event Has Uuid	✅	2023ms
Format Validation.Event Has Lib Properties	✅	2021ms
Format Validation.Distinct Id Is String	✅	2021ms
Format Validation.Token Is Present	✅	2019ms
Format Validation.Custom Properties Preserved	✅	2022ms
Format Validation.Event Has Timestamp	✅	2020ms
Retry Behavior.Retries On 503	❌	7025ms
Retry Behavior.Does Not Retry On 400	✅	4022ms
Retry Behavior.Does Not Retry On 401	✅	4023ms
Retry Behavior.Respects Retry After Header	❌	7023ms
Retry Behavior.Implements Backoff	❌	17022ms
Retry Behavior.Retries On 500	❌	7025ms
Retry Behavior.Retries On 502	❌	7019ms
Retry Behavior.Retries On 504	❌	7024ms
Retry Behavior.Max Retries Respected	❌	17033ms
Deduplication.Generates Unique Uuids	✅	2036ms
Deduplication.Preserves Uuid On Retry	❌	7018ms
Deduplication.Preserves Uuid And Timestamp On Retry	❌	12026ms
Deduplication.Preserves Uuid And Timestamp On Batch Retry	❌	7026ms
Deduplication.No Duplicate Events In Batch	✅	2031ms
Deduplication.Different Events Have Different Uuids	✅	2021ms
Compression.Sends Gzip When Enabled	❌	2016ms
Batch Format.Uses Proper Batch Structure	✅	2016ms
Batch Format.Flush With No Events Sends Nothing	✅	2013ms
Batch Format.Multiple Events Batched Together	✅	2028ms
Error Handling.Does Not Retry On 403	✅	4019ms
Error Handling.Does Not Retry On 413	❌	4020ms
Error Handling.Retries On 408	✅	7025ms

Failures

retry_behavior.retries_on_503

Expected at least 3 requests, got 1

retry_behavior.respects_retry_after_header

Expected at least 2 requests, got 1

retry_behavior.implements_backoff

Expected at least 3 requests, got 1

retry_behavior.retries_on_500

Expected at least 2 requests, got 1

retry_behavior.retries_on_502

Expected at least 2 requests, got 1

retry_behavior.retries_on_504

Expected at least 2 requests, got 1

retry_behavior.max_retries_respected

Expected 4 requests, got 1

deduplication.preserves_uuid_on_retry

Need at least 2 requests to check retry

deduplication.preserves_uuid_and_timestamp_on_retry

Expected at least 3 requests, got 1

deduplication.preserves_uuid_and_timestamp_on_batch_retry

Expected at least 2 requests, got 1

compression.sends_gzip_when_enabled

Header 'Content-Encoding' with value 'gzip' not found in requests

error_handling.does_not_retry_on_413

Expected 1 requests, got 2

[marandaneto]

so we have this

posthog-android/posthog/src/main/java/com/posthog/PostHogConfig.kt

Lines 99 to 103 in be77f61

	/**
	* Preload PostHog remote config automatically
	* Defaults to true
	*/
	public var remoteConfig: Boolean = true,

which was added when remote config was still not considered GA
what we can do is to deprecate this and make it a noop, removing it would break builds

the only problem i see is that if session replay has changed its flags conditions, eg session recording was enabled and now it is disabled, we wont know unless we call remote config again for every reloadfeatureflags() call.

are we ok with keeping session replay running even if it should not or are we ok calling remote config again for every reloadfeatureflags() call?

[dmarticus]

so we have this

posthog-android/posthog/src/main/java/com/posthog/PostHogConfig.kt

Lines 99 to 103 in be77f61

	/**
	* Preload PostHog remote config automatically
	* Defaults to true
	*/
	public var remoteConfig: Boolean = true,

which was added when remote config was still not considered GA
what we can do is to deprecate this and make it a noop, removing it would break builds
the only problem i see is that if session replay has changed its flags conditions, eg session recording was enabled and now it is disabled, we wont know unless we call remote config again for every reloadfeatureflags() call.

are we ok with keeping session replay running even if it should not or are we ok calling remote config again for every reloadfeatureflags() call?

This follows the same pattern as posthog-js, where:

1. Remote config is loaded once at init
2. reloadFeatureFlags() only reloads feature flags, not the full remote config
3. Session replay config changes don't take effect until the next session (page reload/app restart)

We're accepting the same tradeoff here: session replay config staleness until app restart. I think this is a reasonable tradeoff because:

• Session replay config changes are relatively rare (not something that changes frequently for a given user)
• It simplifies the SDK logic
• It reduces API calls to /flags
• It matches the behavior users already experience with posthog-js

If we wanted session replay config to be more responsive, we could add periodic remote config refresh (e.g., every 5 minutes), but that adds complexity and battery/network overhead for a rare scenario. We can always add that later if it becomes a real need.

TL;DR – let's do it this way for now. But open to pushback!

[marandaneto]

whats the expectation here? this would return eg Europe/Vienna

[marandaneto]

@ioannisj can you review this since i've done many changes to account for the behaviour changes