ACRA / acra

Describe the bug

I could not figure out why ACRA would not disable when I set the SharedPreferences key of ACRA_DISABLE to true (noting it was the correct boolean type in the actual file on disk)

I got a clue when I noticed the limiter's lastVersionNr item was being written to a null.xml shared preferences file - "null? that looks like a missing prefs name...)

It turns out that the CoreConfiguration.sharedPreferences name defaults to null, but the comparison for whether a custom shared preference is sent in is comparing it to ""

Compares to a constant that resolves to "":

acra/acra-core/src/main/java/org/acra/prefs/SharedPreferencesFactory.kt

Line 39 in 92416a3

    
           return if (ACRAConstants.DEFAULT_STRING_VALUE != config.sharedPreferencesName) {

But default is null:

acra/acra-core/src/main/java/org/acra/config/CoreConfiguration.kt

Line 43 in 92416a3

val sharedPreferencesName: String? = null,

Expected behavior

I expect if I have not set any custom shared preference name that the default will be to correctly use the main application SharedPreferences

So, either the SharedPreferencesFactory should initialize to ACRAConstants.DEFAULT_STRING_VALUE

acra/acra-core/src/main/java/org/acra/ACRAConstants.kt

Line 54 in 92416a3

const val DEFAULT_STRING_VALUE = ""

...or it should check for null or empty string in it's check

Seems to me that initializing it to empty is cleanest?

Version

Android: all
ACRA [e.g. 5.9.6]

CoreConfiguration.sharedPreferencesName defaults to null but is compared to "" to check for "unset"