You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[shared_preferences] Eager SharedPreferences fetch in LegacySharedPreferencesPlugin executes synchronous disk I/O on Android main thread during startup #195313
Add shared_preferences to any Flutter Android application.
Cold start the application and profile startup with Perfetto or similar.
Observe the RegisterFlutterPlugin step for shared preferences plugin taking a long time than other plugins
Expected results
To reduce the amount of time taken for onAttachedToEngine to complete, synchronous disk I/O should not be executed in it.
Actual results
Since synchronous disk I/O is being done in the onAttachedToEngine method of the LegacySharedPreferencesPlugin, it takes a much longer time to attach to the engine than other plugins.
Code sample
Code sample
In `packages/shared_preferences/shared_preferences_android/android/src/main/kotlin/io/flutter/plugins/sharedpreferences/LegacySharedPreferencesPlugin.kt`:
```kotlinprivatefunsetUp(context:Context) {
// Synchronous disk I/O on the UI thread:
preferences = context.getSharedPreferences(SHARED_PREFERENCES_NAME, Context.MODE_PRIVATE)
try {
SharedPreferencesApiRegistrar().register(this)
} catch (ex:Exception) {
Log.e(TAG, "Received exception while setting up SharedPreferencesPlugin", ex)
}
}
overridefunonAttachedToEngine(binding:FlutterPluginBinding) {
setUp(binding.applicationContext)
}
changed the title [-]Eager SharedPreferences initialization in LegacySharedPreferencesPlugin executes synchronous disk I/O on Android main thread during startup[/-][+]Eager SharedPreferences fetch in LegacySharedPreferencesPlugin executes synchronous disk I/O on Android main thread during startup[/+]on Oct 26, 2026
changed the title [-]Eager SharedPreferences fetch in LegacySharedPreferencesPlugin executes synchronous disk I/O on Android main thread during startup[/-][+][shared_preferences] Eager SharedPreferences fetch in `LegacySharedPreferencesPlugin` executes synchronous disk I/O on Android main thread during startup[/+]on Oct 26, 2026
fwiw context.getSharedPreferences() itself kicks off the xml load on a background thread (SharedPreferencesImpl starts it in the constructor), the blocking part is the first getter that has to wait for that load. so the eager call might mostly cost the file/dir checks and the first read can still block later. would be good to see a perfetto trace that shows which one actually dominates before moving it, otherwise it just shifts the stall to the first read.
Activity
[-]Eager SharedPreferences initialization in LegacySharedPreferencesPlugin executes synchronous disk I/O on Android main thread during startup[/-][+]Eager SharedPreferences fetch in LegacySharedPreferencesPlugin executes synchronous disk I/O on Android main thread during startup[/+][-]Eager SharedPreferences fetch in LegacySharedPreferencesPlugin executes synchronous disk I/O on Android main thread during startup[/-][+][shared_preferences] Eager SharedPreferences fetch in `LegacySharedPreferencesPlugin` executes synchronous disk I/O on Android main thread during startup[/+][shared_preferences_android] Fix eager SharedPreferences fetch in Leg…
[shared_preferences_android] Fix eager SharedPreferences fetch in `Le…
[shared_preferences_android] Fix eager SharedPreferences fetch in `Le…
mbcorona commentedon Oct 26, 2026
Hi @xRossKoh, thanks for the report and PR flutter/packages#13431.
Routing to team-android.
[shared_preferences_android] Fix eager SharedPreferences fetch in `Le…
[shared_preferences_android] Fix eager SharedPreferences fetch in `Le…
[shared_preferences_android] Fix eager SharedPreferences fetch in `Le…
[shared_preferences] Defer SharedPreferences fetch in `LegacySharedPr…
RajKavadia commentedon Oct 28, 2026
fwiw context.getSharedPreferences() itself kicks off the xml load on a background thread (SharedPreferencesImpl starts it in the constructor), the blocking part is the first getter that has to wait for that load. so the eager call might mostly cost the file/dir checks and the first read can still block later. would be good to see a perfetto trace that shows which one actually dominates before moving it, otherwise it just shifts the stall to the first read.
jesswrd commentedon Oct 28, 2026
@xRossKoh From android triage: Has this issue been resolved by flutter/packages#13431?
gmackall commentedon Nov 3, 2026
Closing as flutter/packages#13431 marks this as fixed, please let me know if there is anything outstanding and you'd like to re-open