recordHandledException() causes high CPU load and takes ~300ms to complete

[lengfeld]

tl;dr

We have seen that Countly.sharedInstance().crashes().recordHandledException(Exception exception) blocks for ~300ms (tested on a Google emulator) and causes high CPU load in the installd process.

Can you add an API to disable/overwrite the getDiskSpaces e.g. by overwriting MetricProvider in CountlyConfig?

Tested setup

Countly sdk and test app version: commit b8c5ddc and version 18.01-2460-gb8c5ddc2 (from git describe)

Emulator was Android 16.0 x86_64 with Play Services from Google: Medium Phone API 36.0

Added the lines

    val x = Exception("test")
    Countly.sharedInstance().crashes().recordHandledException(x)

in the file app-kotlin/src/main/java/ly/count/android/demo/kotlin/MainActivity.kt.

Observation

When the app is launched, you see the following traces in perfetto

• The demo app is making a binder call to system_server and blocks. Here on the main_thread
• The system_server is making a binder call to the installd process.
• The installd process does some CPU/IO for 300ms to compute the disk usage.

SDK Code

The disk usage is queried in the function getDiskSpaces(). The code is

                public Map.Entry<String, String> getDiskSpaces(Context context) {
                    long totalBytes = 0;
                    long usedBytes = 0;

                    StorageManager sm = (StorageManager) context.getSystemService(Context.STORAGE_SERVICE);
                    if (sm != null && Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
                        try {
                            for (android.os.storage.StorageVolume sv : sm.getStorageVolumes()) {
                                if (sv.isPrimary()) {
                                    StorageStatsManager stm = (StorageStatsManager) context.getSystemService(Context.STORAGE_STATS_SERVICE);
                                    totalBytes += stm.getTotalBytes(StorageManager.UUID_DEFAULT);
                                    usedBytes += stm.getTotalBytes(StorageManager.UUID_DEFAULT) - stm.getFreeBytes(StorageManager.UUID_DEFAULT);
                                }
                            }
                        } catch (Exception e) {
                            Countly.sharedInstance().L.w("[DeviceInfo] getDiskSpaces, Got exception while trying to get all volumes storage", e);
                        }

The Android docu for getTotalBytes says:

This method may take several seconds to complete, so it should only be called from a worker thread.

Our Need

We would like to avoid the CPU/IO load on our device. Especially because we sometimes log multiple errors per second.

In the file CountlyConfig there is already some methods to overwrite some of the metrics. E.g. setMetricOverride(). But no method to overwrite MetricProvider. Can this be added? Or another API introduced to control whether and how the disk usage is queried?

Thanks for looking into this.

[arifBurakDemiray]

Hey @lengfeld! 👋 Thanks for the detailed report and analysis, really appreciate the deep dive into the installd IPC chain 🔍

We've actually been thinking about this area! One idea we've been exploring is exposing our internal MetricProvider interface publicly through CountlyConfig, so developers could override any device metric they want. For your case, that would mean you could override getDiskSpaces() to return cached values or skip the expensive computation entirely, something like:

CountlyConfig config = new CountlyConfig(context, appKey, serverUrl)
.setMetricProvider(new MetricProvider() {
Override
public Map.Entry<String, String> getDiskSpaces(Context context) {
// return cached/precomputed values to avoid the expensive StorageStatsManager calls
return new AbstractMap.SimpleEntry<>("0", "0");
}
});

The idea is that any method you don't override would still use the SDK defaults, so you'd only touch what you need.

What do you think about this approach? Would this cover your needs, or would you prefer something more targeted like an internal mechanism? Would love to hear your thoughts! 😊

[lengfeld]

@arifBurakDemiray

What do you think about this approach? Would this cover your needs, ...

Yes, this would cover our need. In our case we would just disable disk space metrics with getDiskSpaces() for now. We have not looked at that information yet. And later maybe reintroduce it with caching or a more faster approach. Your API suggestion would give us this possibility and control. I'm in favor for it :-)

Beyond our needs for other users: After the MetricProvider is exposed, the underlying code in the default case would still be the same right? So every library user out there, still has this 300ms CPU time burst in there apps. That's kind of a pity, because the function recordHandledException() is also blocking and waiting these ~300ms. So if this is called on the main-thread by an app, it will produce frame jank/UI stuttering. From the API docs of recordHandledException() it's not clear that this is an issue. E.g. to advance devs to call this function only on background threads.

[arifBurakDemiray]

Hello @lengfeld 🙌

Thanks for the feedback! 🙇 We've opened a PR for the MetricProvider override so you'll be able to disable getDiskSpaces() soon.

For the general 300ms blocking issue in the default case, we'll address that in a future update with internal caching or background offloading. We'll also update the recordHandledException() docs to mention the potential main-thread impact 📝

Will keep you posted! 😊

[lengfeld]

Hi @arifBurakDemiray ,

I have tried out the code in the PR. It works and fixes the issues. I can overwrite the method and avoid the expensive disk stats.

I nevertheless added a comment, because the now public API is ... a bit strange. See https://github.com/Countly/countly-sdk-android/pull/547/changes#diff-c8332da57e09af8a28f2623689b1a711edaafd514eab81cf43986139e832fd25 :-)

[arifBurakDemiray]

Hey @lengfeld! 👋 Great catch on the Map.Entry API, you're absolutely right, that was leaking internal implementation details 😅

We've introduced a DiskMetric data class with clearly named fields (totalMb and usedMb), so the API is now self-documenting:

countlyConfig.setMetricProvider(object : MetricProvider {
    override fun getDiskSpaces(context: Context?): DiskMetric? {
        return DiskMetric("totalHere", "usedHere")
    }
})

Keep in mind this is a pretty advanced-level API, so we expect most developers won't need to interact with it. So for now this is as far as we can go for this issue, but we'll keep improving it in future updates with caching and the general performance fix we discussed.

Really appreciate you testing the PR and giving such detailed feedback, it made the public API much better! 🙌😊

[lengfeld]

@arifBurakDemiray no problem and thanks for resolving this issue so quickly 👍

[arifBurakDemiray]

Hello @lengfeld 🙌

We have released the new Countly Android SDK version 26.1.2
https://github.com/Countly/countly-sdk-android/releases/tag/26.1.2

Which also includes providing metric provider for your information.

Have a great day!

[lengfeld]

Thanks. We used the new API and verified that we could avoid the StorageManager overhead with that. 👍