Once signed up, set up an Android source in the dashboard. You should be able to see a Write Key for this source, as shown below:
You will also need a data plane URL. Refer to the Glossary for more information on the data plane URL and where to find it.
The Setup tab in the RudderStack dashboard (seen above) has an SDK installation snippet containing both the write key and the data plane URL. You can use it to integrate the Android SDK into your project.
Installing the SDK
As Bintray has sunset from 1st May, we’re moving the Android SDK to Maven Central. All the versions from 1.0.10 are available in Maven Central only.
We distribute the Android SDK through Maven Central. The recommended and easiest way to add the SDK to your project is through the Android Gradle build system.
Follow these steps:
Open your project level build.gradle file, and add the following lines of code:
Then open your app/build.gradle and add the dependency under dependencies as shown below:
implementation'com.rudderstack.android.sdk:core:1.7+'// add the following line if you don't have Gson included already
implementation'com.google.code.gson:gson:2+'
It is recommended to use the Core Android SDK without any device-mode destination SDKs as you will have a better view on the captured data from the SDK.
Setting Android permissions
Add this line to your AndroidManifest.xml file of your application for internet permission:
We also declare android.permission.BLUETOOTH and android.permission.ACCESS_WIFI_STATE as optional by mentioning required="false" . If we get these permissions, we’ll capture the Bluetooth status and the WiFi status of the device and pass it under context.network.
Android ProGuard rules
Add the following lines to your Android ProGuard rules if you are using Proguard full mode to optimize your app:
Add the below rules if you are using the Android SDK older than v1.20.0.
Note that the rules are bundled in the SDK itself from v1.20.0 onwards.
// Reporter Module
-keepclasscom.rudderstack.android.ruddermetricsreporterandroid.models.LabelEntity{*;}-keepclasscom.rudderstack.android.ruddermetricsreporterandroid.models.MetricEntity{*;}-keepclasscom.rudderstack.android.ruddermetricsreporterandroid.models.ErrorEntity{*;}// Required for the usage off TypeToken class in Utils.converToMap, Utils.convertToList
-keepclasscom.google.gson.reflect.TypeToken{*;}-keepclass* extendscom.google.gson.reflect.TypeToken// Required for the serialization of SourceConfig once it is downloaded.
-keepclasscom.google.gson.internal.LinkedTreeMap{*;}-keepclass* implementsjava.io.Serializable{*;}-keepclasscom.rudderstack.rudderjsonadapter.RudderTypeAdapter{*;}-keepclass* extendscom.rudderstack.rudderjsonadapter.RudderTypeAdapter// Required to ensure the DefaultPersistenceProviderFactory is not removed by Proguard
// and works as expected even when the customer is not using encryption feature.
-dontwarnnet.sqlcipher.Cursor-dontwarnnet.sqlcipher.database.SQLiteDatabase$CursorFactory-dontwarnnet.sqlcipher.database.SQLiteDatabase-dontwarnnet.sqlcipher.database.SQLiteOpenHelper-keepclasscom.rudderstack.android.sdk.core.persistence.DefaultPersistenceProviderFactory{*;}// Required for the usage of annotations across reporter and web modules
-dontwarncom.fasterxml.jackson.annotation.JsonIgnore-dontwarncom.squareup.moshi.Json-dontwarncom.fasterxml.jackson.annotation.JsonProperty// Required for Device Mode Transformations
-keepclasscom.rudderstack.android.sdk.core.TransformationResponse{*;}-keepclasscom.rudderstack.android.sdk.core.TransformationResponseDeserializer{*;}-keepclasscom.rudderstack.android.sdk.core.TransformationRequest{*;}
Initializing the RudderStack client
Import the library on the classes you desire to use RudderClient library
importcom.rudderstack.android.sdk.core.*;
Add the following code to the onCreate method in your Application class:
The Android SDK integrates with the OneTrust consent manager and lets you specify the user’s consent during initialization. For more information, refer to the OneTrust Consent Management for Android guide.
Configuring your RudderStack client
You can configure your client based on the following methods using RudderConfig.Builder:
Method
Type
Description
withLogLevel
Integer
Controls the log details you want to capture using the SDK.
Default value: RudderLogger.RudderLogLevel.NONE
withDataPlaneUrl
String
Your data plane URL.
Default value: https://hosted.rudderlabs.com
withDbThresholdCount
Integer
Number of events to be saved in the SQLite database. Once the limit is reached, older events are deleted from the database.
Default value: 10000
withSleepcount
Integer
Minimum waiting time to flush the events to the RudderStack server. The minimum value can be set to 1 second.
Default value: 10 seconds
withEventDispatchSleepInterval
Integer
Duration (in seconds) for which the event dispatch thread sleeps when the SDK has no events to send to RudderStack. This value should be less than or equal to the value set using withSleepCount.
Default value: 1 second
withConfigRefreshInterval
Integer
Time after which the SDK fetches the config from the dashboard.
Default value: 2 hours
withTrackLifecycleEvents
Boolean
Determines if the SDK should automatically capture application lifecycle events using the activity lifecycle callbacks.
Default value: true
withNewLifecycleEvents
Boolean
Determines if the SDK should automatically capture application lifecycle events using AndroidX’s LifecycleObserver class. See Tracking events with AndroidX LifecycleObserver for more information.
Default value: false
withTrackDeepLinks
Boolean
Determines if the SDK should send the deep link-specific details as a Deep Link Opened event. See Tracking deep links for more information.
Maximum inactivity period before the session expires.
Default value: 300000 ms (5 minutes)
withRecordScreenViews
Boolean
Determines if the SDK should automatically capture the screen view events.
Default value: false
withGzip
Boolean
Gzips the event requests.
Default value: true
withCollectDeviceId
Boolean
Determines if the SDK should automatically collect the device ID. If set to false, it does not send context.device.id as a part of the event payload. See Disabling device ID collection for more information.
Default value: true
withAutoCollectAdvertId
Boolean
Determines if the SDK should automatically collect the advertisement ID.
The withDbEncryption method accepts a DbEncryption object with the following parameters:
Parameter
Data type
Description
true/false
Boolean
Specifies whether to encrypt an unencrypted database or decrypt an encrypted database.
key
String
Key used to encrypt/decrypt the database.
After you encrypt the database:
If no key is provided, then the SDK deletes the current database with unsent events and creates a new unencrypted database instead.
If a wrong key is provided, then the SDK deletes the current database with unsent events and creates a new encrypted database with the given key.
The SDK does not store the key, so it cannot determine whether the entered key is right or wrong. Hence, if the key cannot decrypt the database, the SDK assumes it to be incorrect and deletes the old events and database.
Self-hosted control plane
If you are using a device mode destination like Adjust, Firebase, etc., the Android SDK needs to fetch the required configuration from the Control Plane. If you are using the Control plane lite utility to host your own Control Plane, then follow the steps in this section and specify controlPlaneUrl in yourRudderConfig.Builder that points to your hosted source configuration file.
You shouldn’t pass the controlPlaneUrl parameter during SDK initialization if you are using the dashboard from RudderStack Cloud Dashboard. This parameter is supported only if you are using our open-source Control plane lite to self-host your Control Plane.
Gzipping requests
The Gzip feature is enabled by default in the Android SDK.
The Android SDK automatically gzip-compresses event requests. To disable this feature, set the Gzip parameter to false while initializing the SDK:
Gzip requires rudder-serverv1.4 or higher. Otherwise, your events might fail.
Identify
The identify call lets you identify a visiting user and associate them to their actions. It also lets you record the traits about them like their name, email address, etc. Once you identify the user, the SDK persists all the user information and passes it on to the subsequent track or screen calls. To reset the user identification, you can use the reset method.
Note that:
For older SDK versions (< v1.18.0), the Android SDK captures the device ID and uses that as anonymousId for identifying the user. This helps the SDK to track the users across the application installation.
On Android devices, the deviceId is assigned during the first boot. It remains consistent across the applications and installs and changes only after factory reset.
Starting from v1.18.0, the SDK uses a UUID as anonymousId instead of the device ID. If you are upgrading from a previous SDK version, see How RudderStack sets anonymous ID for more information on how the SDK collects and sets anonymousId.
If you are upgrading to the latest SDK from a previous version (< v1.18.0) and disabling device ID collection using withCollectDeviceId(false):
Make sure your user transformations are not dependent on context.device.id as the SDK will not send this value in the event payload.
The context.device.id column in your warehouse destination will not be populated henceforth (it will still contain data populated by the previous SDK version).
How SDK sets anonymous ID
For direct/fresh SDK installation
For a fresh installation of the Android SDK v1.18.0 and later, RudderStack uses UUID as anonymousId regardless of whether withCollectDeviceId is set to true or false.
For updating SDK from older version
If you are updating your Android SDK from an older version (< v1.18.0), then:
RudderStack will continue to use the device ID as anonymousId - it will not break the existing SDK behavior until you set withCollectDeviceId to false.
If you set withCollectDeviceId to false, the SDK checks if the existing anonymousId is a device ID. If yes, it sets a new UUID as the anonymousId.
If you have used the putAnonymousId method to set your own anonymousId, then the SDK will not modify it even if you set withCollectDeviceId to false.
Setting a custom ID
You can pass a custom ID along with the standard userId in your identify calls. RudderStack adds this value under context.externalId.
RudderStack supports passing externalId only in the identify events. You must not pass this ID in other API calls like track, page, etc.
The following snippet shows how to add an externalId to your identify event:
Extra data properties you want to send along with the event
options
RudderOption
No
Extra event options
Screen
You can use the screen call to record whenever the user sees a screen on the mobile device. You can also send some extra properties along with this event.
Category of the screen visited, such as HomeScreen, LoginScreen. Useful for tracking multiple Fragment views under a single Activity.
property
RudderProperty
No
Extra property object that you want to pass along with the screen call.
option
RudderOption
No
Extra options to be passed along with screen event.
Group
The group call associates a user to a specific organization. A sample group call for the API is below:
rudderClient.group("sample_group_id",RudderTraits().putAge("24").putName("Test Group Name").putPhone("1234567891"))
rudderClient.group("sample_group_id",newRudderTraits().putAge("24").putName("Test Group Name").putPhone("1234567891"));
Follow the method signatures below:
Name
Data Type
Required
Description
groupId
String
Yes
An ID of the organization with which you want to associate your user
traits
RudderTraits
No
Any other property of the organization you want to pass along with the call
options
RudderOption
No
Event level options
RudderStack doesn’t persist the traits for the group across the sessions.
Alias
The alias call associates the user with a new identification. A sample alias call for the API is below:
rudderClient.alias("test_new_id")
rudderClient.alias("test_new_id");
Alternatively, you can use the following method signature
Name
Data Type
Required
Description
newId
String
Yes
The new userId you want to assign to the user
options
RudderOption
No
Event level option
RudderStack replaces the old userId with the newUserId and we persist that identification across the sessions.
Reset
You can use the reset method to clear the persisted user traits. It also resets the anonymousId with a new UUID if you call it with true (for SDK v1.18.0 and later). To clear only user traits, call reset with false.
In session tracking, calling the reset method clears the current sessionId and generates a new one.
A sample reset call is shown:
rudderClient.reset(false)
rudderClient.reset(false);
Consent-driven user tracking (GDPR support)
RudderStack gives the users the ability to opt out of tracking any user activity until the user gives their consent. You can do this using the SDK’s optOut API.
The optOut API takes true or false as a Boolean value to enable or disable tracking user activities. This flag persists across device reboots.
The following snippet highlights the use of the optOut API to disable user tracking:
rudderClient.optOut(true)
rudderClient.optOut(true);
the user grants their consent, you can enable user tracking once again by using the optOut API with false as a parameter sent to it:
rudderClient.optOut(false)
rudderClient.optOut(false);
The optOut API is available in the Android SDK from v1.0.21 onwards.
Setting the Android device token
You can set your device-token for push notification to be sent to the destinations that support Push Notification. We set the token under context.device.token.
Follow the code snippets below:
RudderClient.putDeviceToken("your_device_token")
RudderClient.putDeviceToken("your_device_token");
Setting custom context
You can set custom contextual information in Android SDK by using either of the following ways:
During SDK initialization
Set custom context during SDK initialization as follows:
This feature is available in the Android SDK v1.22.0 and later.
The Android SDK persists the contextual information set during SDK initialization for subsequent events but not across sessions.
Calling the reset method clears all the contextual information set during SDK initialization.
The contextual information passed at the event level gets precedence over the context set during SDK initialization.
Using putCustomContext method
Use the putCustomContext method on an instance of RudderOption to set custom contextual information as a nested object within context while sending the events.
An example of setting custom context using an instance of RudderOption and passing it in a track call:
The SDK does not persist the contextual information set using putCustomContext for subsequent events. Hence, you must use this method every time you want to set custom context for an event.
Setting the advertisement ID
By default, RudderStack collects the advertisement ID only if the following three conditions are met:
com.google.android.gms.ads.identifier.AdvertisingIdClient is present in your application’s class path.
limitAdTrackingis not enabled for your device.
Use the putAdvertisingId method to set the advertisement ID:
RudderClient.putAdvertisingId("sampleAdvertId")
RudderClient.putAdvertisingId("advertId");
The putAdvertisingId method is static and can be called before or after the SDK initialization.
If withAutoCollectAdvertId is set to true and you set the advertisement ID value using putAdvertisingId method, RudderStack uses the value provided by the user instead of collecting it automatically.
Once you reset the advertisement ID using the clearAdvertisingId method, RudderStack starts auto-collecting the advertisement ID again.
To clear the advertisement ID, use the clearAdvertisingId method:
rudderClient.clearAdvertisingId()``
RudderClient.with(this).clearAdvertisingId();
The clearAdvertisingId method is not static and hence can be called only after the SDK initialization.
RudderStack sets gaid under context.device.advertisementId.
Filtering events
When sending events to a destination via device mode, you can explicitly specify which events should be discarded or allowed to flow through - by allowlisting or denylisting them.
The RudderStack Android SDK allows you to enable or disable event flow to a specific destination or all destinations to which the source is connected. You can specify these destinations by creating a RudderOption object as shown:
valoption=RudderOption()//default value for `All` is true
option.putIntegration("All",false)// specifying destination by its display name
option.putIntegration("Google Analytics",true)option.putIntegration(<DESTINATIONDISPLAYNAME>,<boolean>)// specifying destination by its Factory object
option.putIntegration(AppcenterIntegrationFactory.FACTORY,true);option.putIntegration(<RudderIntegration.FACTORY>,<boolean>);
RudderOptionoption=newRudderOption();// default value for `All` is true
option.putIntegration("All",false);// specifying destination by its display name
option.putIntegration("Google Analytics",true);option.putIntegration(<DESTINATIONDISPLAYNAME>,<boolean>);// specifying destination by its Factory object
option.putIntegration(AppcenterIntegrationFactory.FACTORY,true);option.putIntegration(<RudderIntegration.FACTORY>,<boolean>);
The keyword All in the above snippet represents all destinations the source is connected to. Its value is set to true by default.
Make sure the destination display name that you pass while specifying the destinations should exactly match the destination name as shown here.
You can pass the destinations specified in the above snippet to the SDK in two ways:
1. While initializing the SDK
This is helpful when you want to enable/disable sending the events across all event calls made using the SDK to the specified destination(s).
varrudderClient=RudderClient.getInstance(this,WRITE_KEY,RudderConfig.Builder().withDataPlaneUrl(DATA_PLANE_URL).build(),// passing the rudderoption object containing
// the list of destination(s) you specified
option)
RudderClientclient=RudderClient.getInstance(this,<write_key>,newRudderConfig.Builder().withEndPointUri(<end_point_url>).build(),option// passing the rudderoption object containing the list of destination(s) you specified
);
2. While sending events
This approach is helpful when you want to enable/disable sending only a particular event to the specified destination(s) or if you want to override the specified destinations passed with the SDK initialization for a particular event.
rudderClient.track("Product Added",RudderProperty().putValue("product_id","product_001"),// passing the rudderoption object
// containing the list of destination you specified
option)
rudderClient.track("Product Added",newRudderProperty().putValue("product_id","product_001"),option// passing the rudderoption object containing the list of destination(s) you specified
);
If you specify the destinations both while initializing the SDK as well as while making an event call, then the destinations specified at the event level only will be considered.
Tracking user sessions
By default, the Android SDK automatically tracks the user sessions. This means that RudderStack automatically determines the start and end of a user session depending on the inactivity time configured in the SDK (default time is 5 minutes).
To automatically track sessions in the Android SDK, withTrackLifecycleEvents should also be set to true. This is because RudderStack considers the Application Opened, Application Installed, or Application Updated events as the start of a new session.
valrudderClient=RudderClient.getInstance(this,WRITE_KEY,RudderConfig.Builder().withDataPlaneUrl(DATA_PLANE_URL)// Set to false to disable automatic session tracking
.withAutoSessionTracking(true).withSessionTimeoutMillis(5*60*1000).build())
RudderClientrudderClient=RudderClient.getInstance(this,WRITE_KEY,newRudderConfig.Builder().withDataPlaneUrl(DATA_PLANE_URL).withAutoSessionTracking(true)// Set to false to disable automatic session tracking
.withSessionTimeoutMillis(5*60*1000).build());
To disable automatic session tracking, set withAutoSessionTracking to false.
For more information on the user sessions and how to track them using the Android SDK, see Session Tracking.
Getting the session ID
To retrieve a session’s sessionId, use the getSessionId() method.
getsessionId() is available in the Android SDK from v1.19.0 onwards.
To disable tracking these events, set the withTrackLifecycleEvents method to false while initializing the SDK. However, it is highly recommended to keep them enabled.
Tracking events with AndroidX LifecycleObserver
Starting from version 1.14.0, the Android SDK supports a newer and more efficient way of tracking your application lifecycle events using the AndroidX LifecycleObserver class, as opposed to the standard method of tracking lifecycle events (using the ActivityLifecycleCallbacks).
To track lifecycle events with this method, add the following dependencies to your app:
If withNewLifecycleEvents is set to true but the required dependencies are missing in your app, the Android SDK will fall back to tracking lifecycle events using the default method withTrackLifeCycleEvents (if set to true while initializing the SDK).
The following table details the lifecycle event tracking matrix:
New way of tracking lifecycle events (withNewLifecycleEvents)
Standard way of tracking lifecycle events (withTrackLifecycleEvents)
Presence of AndroidX LifecycleObserver dependencies in app
Resultant way
Enabled
Enabled
Yes
New
Enabled
Enabled
No
Standard
Enabled
Disabled
No
Lifecycle events are not tracked.
Enabled
Disabled
Yes
New
Disabled
Enabled
NA
Standard
Disabled
Disabled
NA
Lifecycle events are not tracked.
Tracking deep links
Starting from version 1.14.0, the Android SDK sends a Deep Link Opened event when you open any app from a deep link. It also sends all the deep link-related details as the event properties. In the previous versions, the SDK included these details as a part of the Application Opened event properties.
This feature is turned on by default. To turn it off, set withTrackDeepLinks to false while initializing the SDK - this causes the SDK to stop sending any additional Deep Link Opened events.
After you set up the deep link in your Android app, you can trigger the deep linking as follows:
Represents a Uniform Resource Locator used to identify a location on the network and a mechanism for retrieving it. URLs are used to open web pages, access APIs, and deep link into specific parts of the app.
For example, https://example.com/_app.
referring_application
String
Used to indicate the originating page or app when opening a URL.
For example, https://test.com/_app.
The Android SDK also adds the query parameters as the deep link event properties.
Debugging
If you run into any issues regarding the RudderStack Android SDK, you can turn on the VERBOSE or DEBUG logging to find out what the issue is. To turn on the logging, change your RudderClient initialization to the following:
Google Chromecast is a device that plugs into your TV or monitor with an HDMI port, and can be used to stream content from your phone or computer.
RudderStack supports integrating the Android SDK with your Cast app. Follow these instructions to build your Android sender app. Then, add the Android SDK to it. Follow the Google Cast developer guide for more details.
Developing a device mode destination
You can easily develop a device mode destination in case RudderStack doesn’t support it already, by following the steps listed in this section.
importandroidx.annotation.NonNull;importandroidx.annotation.Nullable;importcom.rudderstack.android.sdk.core.RudderClient;importcom.rudderstack.android.sdk.core.RudderConfig;importcom.rudderstack.android.sdk.core.RudderIntegration;importcom.rudderstack.android.sdk.core.RudderLogger;importcom.rudderstack.android.sdk.core.RudderMessage;publicclassCustomFactoryextendsRudderIntegration<CustomFactory>{privatestaticfinalStringFACTORY_KEY="Custom Factory";publicstaticFactoryFACTORY=newFactory(){@OverridepublicRudderIntegration<?>create(Objectsettings,RudderClientclient,RudderConfigrudderConfig){returnnewCustomFactory(client,rudderConfig);}@OverridepublicStringkey(){returnFACTORY_KEY;}};privateCustomFactory(@NonNullRudderClientclient,RudderConfigconfig){}privatevoidprocessRudderEvent(RudderMessageelement){System.out.println("Processing RudderEvent of type "+element.getType());}@Overridepublicvoidreset(){System.out.println("Reset is called");}@Overridepublicvoidflush(){System.out.println("Flush is called");}@Overridepublicvoiddump(@NullableRudderMessageelement){try{if(element!=null){processRudderEvent(element);}}catch(Exceptione){RudderLogger.logError(e);}}@OverridepublicCustomFactorygetUnderlyingInstance(){returnthis;}}
Some pointers to keep in mind:
You can use the constructor of the CustomFactory class to initialize the native SDK of the device mode destination you are working on.
RudderStack’s Android SDK dumps every event it receives to the dump() method of the CustomFactory class. From here, you can process the event and hand it over to the native SDK of the device mode destination.
The SDK also triggers the reset() method of the CustomFactory class on every reset() call made via the SDK. You can use this to handle the destination-specific reset.
RudderStack’s Android SDK also triggers the flush() method of the CustomFactory class on every flush() call made via the SDK which you can use to handle the destination-specific reset logic. You can make a flush call using the SDK as shown below:
rudderClient.flush()
rudderClient.flush();
Make sure you return a valid value from getUnderlyingInstance() as it is used by the Android SDK to validate CustomFactory.
Make sure you do not duplicate the value of FACTORY_KEY across multiple CustomFactory that you develop.
Register CustomFactory with the RudderStack Android SDK during its initialization:
Add the function tlsBackport() in your MainActivity as shown:
privatefuntlsBackport(){try{ProviderInstaller.installIfNeeded(this)Log.e("Rudder","Play present")valsslContext:SSLContext=SSLContext.getInstance("TLSv1.2")sslContext.init(null,null,null)sslContext.createSSLEngine()}catch(e:GooglePlayServicesRepairableException){// Prompt the user to install/update/enable Google Play services.
GoogleApiAvailability.getInstance().showErrorNotification(this,e.connectionStatusCode)Log.e("Rudder","Play install")}catch(e:GooglePlayServicesNotAvailableException){// Indicates a non-recoverable error: let the user know.
Log.e("SecurityException","Google Play Services not available.")e.printStackTrace()}}
Finally, call the tlsBackport() function at the very beginning of your onCreate() method in MainActivity.
Can I disable event tracking until the user gives their consent?
Yes, you can.
RudderStack gives you the ability to disable tracking any user activity until the user gives their consent, by leveraging the optOut API. This is required in cases where your app is audience-dependent (e.g. minors) or where you’re using the app to track the user events (e.g. EU users) to meet the data protection and privacy regulations.
The optOut API takes true or false as a Boolean value to enable or disable tracking user activities. So, to disable user tracking, you can use the optOut API as shown:
rudderClient.optOut(true)
Once the user gives their consent, you can enable user tracking again:
You only need to call the optOut API with the required parameter once, as the information persists within the device even if you reboot it.
How does the SDK handle different client/server errors?
In case of client-side errors, e.g. if the source write key passed to the SDK is incorrect, RudderStack gives you a 400 Bad Request response and aborts the operation immediately.
For other types of network errors (e.g. Invalid Data Plane URL), the SDK tries to flush the events to RudderStack in an incremental manner (every 1 second, 2 seconds, 3 seconds, and so on).
Can I apply encryption only on new databases?
Database encryption works on new and existing databases. Pass the DbEncryption object in RudderConfig.Builder() while initializing the Android SDK.
You can use this object to convert an unencrypted database into an encrypted database and vice versa.
This site uses cookies to improve your experience while you navigate through the website. Out of
these
cookies, the cookies that are categorized as necessary are stored on your browser as they are as
essential
for the working of basic functionalities of the website. We also use third-party cookies that
help
us
analyze and understand how you use this website. These cookies will be stored in your browser
only
with
your
consent. You also have the option to opt-out of these cookies. But opting out of some of these
cookies
may
have an effect on your browsing experience.
Necessary
Always Enabled
Necessary cookies are absolutely essential for the website to function properly. This
category only includes cookies that ensures basic functionalities and security
features of the website. These cookies do not store any personal information.
This site uses cookies to improve your experience. If you want to
learn more about cookies and why we use them, visit our cookie
policy. We'll assume you're ok with this, but you can opt-out if you wish Cookie Settings.