The Android SDK uses an internal OkHttp client by default. If your app already standardizes networking with a custom OkHttpClient, you can pass that client into the SDK configuration.
This is useful when you need custom timeouts, interceptors, logging, certificate pinning, or other shared network settings.
When to customize the client
Use a custom client when your app already has a shared OkHttp setup that should also apply to tracking requests.
Keep the SDK default client if you do not need custom network behavior.
Example
class SampleApplication : Application() {
override fun onCreate() {
super.onCreate()
val okHttpClient = OkHttpClient.Builder()
.readTimeout(15, TimeUnit.SECONDS)
.build()
val configuration = WebtrekkConfiguration.Builder(
trackIds = listOf("11111111111111111"),
trackDomain = "https://your-trackdomain.com"
)
.okHttpClient(okHttpClient)
.build()
Webtrekk.getInstance().init(this, configuration)
}
}public class SampleApplication extends Application {
@Override
public void onCreate() {
super.onCreate();
OkHttpClient okHttpClient = new OkHttpClient.Builder()
.readTimeout(15, TimeUnit.SECONDS)
.build();
WebtrekkConfiguration configuration = new WebtrekkConfiguration.Builder(
Arrays.asList("11111111111111111"),
"https://your-trackdomain.com"
)
.okHttpClient(okHttpClient)
.build();
Webtrekk.getInstance().init(this, configuration);
}
}What stays unchanged
Passing a custom OkHttp client changes how the SDK performs network requests, but it does not change your tracking API usage. Tracking setup, events, and request scheduling continue to work through the normal SDK interfaces.
Notes
Only pass a custom client if you intentionally want the SDK to use your networking configuration.
Make sure the client can reach your track domain without app-specific restrictions.
If you customize timeouts or interceptors, validate the behavior in your app environment before publishing.
Related: Configure Global Tracking, Configure WorkManager Constraints