androidandroid-native-library

Jetpack DataStore native lib is added to bundle: libdatastore_shared_counter.so - what is that?


Recently I noticed that in new projects where I use Jetpack Datastore I have a new native lib added to apps' bundle:

bundle.abb\base\lib\arm64-v8a\libdatastore_shared_counter.so

What is that exactly?

and yeah I didn't have it previously with:

androidxDataStore = "1.0.0"

but got it after updating to:

androidxDataStore = "1.1.0"

update:

the issue here that now Google Play Console shows me a warning about debug symbols:

enter image description here

I tried to add

android {
    ...
    buildTypes {
        ...
        release {
            ...
            ndk {
                debugSymbolLevel = "FULL"
            }
        }
    }

as described here

But it didn't change anything...


Solution

  • This appears to be related to: androidx/datastore/multiprocess/SharedCounter.kt, which may provide backend access control. See androidx.datastore.core, for example DataStoreImpl<T>:

    /**
     * If downstream flow is UnInitialized, no data has been read yet, we need to trigger a new
     * read then start emitting values once we have seen a new value (or exception).
     *
     * If downstream flow has a ReadException, there was an exception last time we tried to read
     * data. We need to trigger a new read then start emitting values once we have seen a new
     * value (or exception).
     *
     * If downstream flow has Data, we should start emitting from downstream flow as long as its
     * version is not stale compared to the version read from the shared counter when we enter
     * the flow.
     *
     * If Downstream flow is Final, the scope has been cancelled so the data store is no
     * longer usable. We should just propagate this exception.
     *
     * State always starts at null. null can transition to ReadException, Data or
     * Final. ReadException can transition to another ReadException, Data or Final.
     * Data can transition to another Data or Final. Final will not change.
     */
    

    The name multiprocess just doesn't align with the definition of "multiprocessing", which involves multiple processors - because in reality, it doesn't matter on which processor a forked thread runs.