BUG : Profiler reports high CPU usage even in background

[YvesDelerm]

Hello, While investigating on our app's CPU and battery usage, we found out that Rudderstack has the thread that uses the most CPU in background for our app.

To Reproduce Steps to reproduce the behavior:

1. Initialise Android SDK
2. Put our app in background
3. Look at Android Studio CPU profiler
4. Rudderstack's thread is the one that uses the most CPU (please see first screenshot)
5. Rudderstack's thread is waked up every 15s approximately

Expected behavior Rudderstack should use less CPU Using withSleepCount parameter should allow Rudderstacks's thread to sleep for longer (for instance 50s as set in the example) Using withSessionTimeout parameter is not applied to app in background (maybe when the app is killed ?)

Screenshots If applicable, add screenshots to help explain your problem.

Version of the Android SDK Rudder Android SDK : v. 1.22.0 No specific device model or OS version

SDK initialisation snippet Please provide the following information:

1. Share the code snippet used for initializing the Android SDK

   RudderClient.getInstance(
           context,
           rudderStackApiKey,
           RudderConfig.Builder()
               .withDataPlaneUrl(rudderStackUrl)
               .withLogLevel(logLevel)
               .withSleepCount(50)
               .withTrackLifecycleEvents(true)
               .withRecordScreenViews(true)
               .build(),
   )

2. Indicate if the SDK initialization depends on any specific condition or event (e.g., initialization of the Android SDK after Firebase initialization or initialization in a callback) => no specific condition nor event

Check for Correct Usage of writeKey and dataPlaneUrl Confirm that the correct writeKey and dataPlaneUrl are utilized during SDK initialization => yes, they are

Could you help us on that, please ? Thanks in advance

[itsdebs]

Thanks for reporting. We will check on this one.

[Oleur]

Any update on this one? :)

[YvesDelerm]

Hello, any news on this issue ?

[1abhishekpandey]

Apologies for the delayed response. We are looking into this and will get back to you soon with an update.