Android - Disk violation on capturing transactions

[HeroOussama]

Integration

sentry-android

Build System

Gradle

AGP Version

8.7.0

Proguard

Enabled

Version

8.17.0

Steps to Reproduce

Enable strict mode in debug mode

Expected Result

No disk violation , no execution on main thread.

Actual Result

Getting disk violations
StrictMode policy violation; ~duration=122 ms: android.os.strictmode.DiskReadViolation (Ask Gemini) at android.os.StrictMode$AndroidBlockGuardPolicy.onReadFromDisk (StrictMode.java:1556) at java.io.UnixFileSystem.list (UnixFileSystem.java:344) at java.io.File.list(File.java:1131) at java.io.File.listFiles(File.java:1216) at io.sentry.android.core.internal.util.CpuInfoUtils.readMaxFrequencies(CpuInfoUtils.java:45) at io.sentry.android.core.DeviceInfoUtil.collectDeviceInformation(DeviceInfoUtil.java:141) at io.sentry.android.core.DefaultAndroidEventProcessor.setDevice(DefaultAndroidEventProcessor.java:187) at io.sentry.android.core.DefaultAndroidEventProcessor.setCommons(DefaultAndroidEventProcessor.java:144) at io.sentry.android.core.DefaultAndroidEventProcessor.process(DefaultAndroidEventProcessor.java:356) at io.sentry.SentryClient.processTransaction(SentryClient.java:512) at io.sentry.SentryClient.captureTransaction(SentryClient.java:903) at io.sentry.Scopes.captureTransaction(Scopes.java:833) at io.sentry.SentryTracer.finish(SentryTracer.java:289) at io.sentry.SentryTracer.finish(SentryTracer.java:654) at io.sentry.SentryTracer.finish(SentryTracer.java:647) at com.hungerstation.perfmon.SentryTrace.stop(SentryTrace.kt:23) at com.hungerstation.perfmon.SentryPerformanceTracker.stopTrace(SentryPerformanceTracker.kt:54) at com.deliveryhero.performance.core.analytics.PerformanceTrackingManagerImpl.stopTrace(PerformanceTrackingManagerImpl.kt:56) at com.hungerstation.perfmon.HsTtiPerformanceManager.stopAppStartToInteractiveTrace(HsTtiPerformanceManager.kt:69) at com.hungerstation.perfmon.PerfMonManager.stopAppStartToInteractiveTrace(PerfMonManager.kt:75) at com.hungerstation.hs_core.performance.HomePerformanceTracer.stopAppTrace(HomePerformanceTracer.kt:63) at com.hungerstation.hs_core.performance.HomePerformanceTracer.tryToStopAppTti(HomePerformanceTracer.kt:93) at com.hungerstation.android.web.v6.screens.main.fragments.newhome.view.HomeModularizationFragment.endHomeAndAppPerformanceTraces(HomeModularizationFragment.kt:2054) at com.hungerstation.android.web.v6.screens.main.fragments.newhome.view.HomeModularizationFragment.renderEmptyHomeMultiActionLandingPage(HomeModularizationFragment.kt:912) at com.hungerstation.android.web.v6.screens.main.fragments.newhome.view.HomeModularizationFragment.handleNoLocationLandingPage(HomeModularizationFragment.kt:916) at com.hungerstation.android.web.v6.screens.main.fragments.newhome.view.HomeModularizationFragment.LocationNotDetected(HomeModularizationFragment.kt:779) at com.hungerstation.android.web.v6.service.location.LocationManagerNew.handleLocationSettingsFailure(LocationManagerNew.java:222) at com.hungerstation.android.web.v6.service.location.LocationManagerNew.lambda$startLocationUpdates$1(LocationManagerNew.java:215) at com.hungerstation.android.web.v6.service.location.LocationManagerNew.$r8$lambda$OdQRO4yq9tsAdPmI-gak4HEUYZ8 (Unknown Source:0) at com.hungerstation.android.web.v6.service.location.LocationManagerNew$$ExternalSyntheticLambda1.onFailure (D8$$SyntheticClass:0) at com.hungerstation.platform.gms.tasks.GmsTask.addOnFailureListener$lambda$3(GmsTask.kt:34) at com.hungerstation.platform.gms.tasks.GmsTask.$r8$Lambda$ieDPs31Xk7DRuT4d_WexJxqcP7E (Unknown Source:0) at com.hungerstation.platform.gms.tasks.GmsTask$$ExternalSyntheticLambda2.onFailure (D8$$SyntheticClass:0)

[linear]

JAVA-228

[romtsn]

hi @HeroOussama thanks for reporting the issue. Currently this is by design of the SDK that we enrich our telemetry with the system/device details on the calling thread. We try our best to pre-load the heavy things on a background thread, but for some cases (like yours) there's not enough time to preload and we do that synchronously.

If this issue is critical for you, I'd suggest to offload the finish() call to a background thread. This method has an overload that allows passing a SentryDate to indicate the end timestamp of the span/transaction, so you could use that to propagate correct timings.

We have a plan to rework the SDK to become more Android-friendly and do most of the things async, but this is a bigger project which we'll probably scope for the next major version. That said, I'm going to close the issue for now, but feel free to reply here if there's some other questions. Thank you!