Introduction

addPreferencesFromResource(...) belonged to the older PreferenceActivity model and is not the modern answer for Android settings screens. Today, the preferred replacement is PreferenceFragmentCompat from AndroidX, using setPreferencesFromResource(...) inside the fragment.

Move from PreferenceActivity to PreferenceFragmentCompat

The old pattern loaded preferences directly inside an activity. Modern Android apps use a fragment-based approach instead because it fits better with current lifecycle, navigation, and app architecture patterns.

A typical replacement looks like this:

1import android.os.Bundle
2import androidx.appcompat.app.AppCompatActivity
3import androidx.preference.PreferenceFragmentCompat
4
5class SettingsActivity : AppCompatActivity() {
6    override fun onCreate(savedInstanceState: Bundle?) {
7        super.onCreate(savedInstanceState)
8
9        supportFragmentManager
10            .beginTransaction()
11            .replace(android.R.id.content, SettingsFragment())
12            .commit()
13    }
14}
15
16class SettingsFragment : PreferenceFragmentCompat() {
17    override fun onCreatePreferences(savedInstanceState: Bundle?, rootKey: String?) {
18        setPreferencesFromResource(R.xml.preferences, rootKey)
19    }
20}

This is the direct conceptual replacement for the old API.

Why the New Pattern Is Better

Using PreferenceFragmentCompat gives you:

• AndroidX support
• fragment lifecycle integration
• easier navigation and back-stack behavior
• compatibility with modern theme and toolbar setups

It also makes settings screens easier to compose. Instead of one giant activity-centric settings class, you can separate settings into fragments by category when the app grows.

Keep the XML Preference Resource

The XML itself usually stays familiar. You still define preferences in a resource file such as res/xml/preferences.xml.

1<PreferenceScreen xmlns:app="http://schemas.android.com/apk/res-auto">
2    <SwitchPreferenceCompat
3        app:key="notifications"
4        app:title="Enable notifications"
5        app:defaultValue="true" />
6
7    <EditTextPreference
8        app:key="username"
9        app:title="Username" />
10</PreferenceScreen>

The main change is not the preference XML. The main change is where and how it gets attached to the UI.

Add the AndroidX Preference Dependency

If the project does not already use AndroidX preferences, add the dependency first.

dependencies {
    implementation "androidx.preference:preference-ktx:1.2.1"
}

Once that is present, PreferenceFragmentCompat and the newer preference widgets are available.

Host the Fragment Like a Normal Modern Screen

Another advantage of the fragment-based approach is that settings can now live inside a normal AppCompatActivity with a toolbar, navigation support, and the same theming approach as the rest of the app. That makes migration easier because you are no longer treating the settings screen as a special legacy island with a separate UI model.

If the app uses Navigation Component, the settings fragment can also participate in the existing navigation graph instead of being launched through old PreferenceActivity patterns.

That integration becomes especially useful once settings screens need deep links, nested navigation, or separate preference categories.

Handle Preference Changes the Modern Way

You can still look up preferences and listen for changes inside the fragment or through SharedPreferences.

1override fun onResume() {
2    super.onResume()
3    preferenceManager.sharedPreferences
4        ?.registerOnSharedPreferenceChangeListener(listener)
5}
6
7override fun onPause() {
8    preferenceManager.sharedPreferences
9        ?.unregisterOnSharedPreferenceChangeListener(listener)
10    super.onPause()
11}

That behavior is familiar, but the fragment-based structure keeps it aligned with the rest of a modern Android app.

Common Pitfalls

• Replacing addPreferencesFromResource with newer widgets while still keeping the old activity-centric mental model.
• Forgetting to add the AndroidX preference dependency before using PreferenceFragmentCompat.
• Mixing legacy preference classes with AndroidX classes in the same screen.
• Assuming the XML preference file itself must be rewritten completely when only the hosting pattern changed.
• Registering preference listeners without respecting the fragment lifecycle.

Summary

• The modern replacement for addPreferencesFromResource(...) is PreferenceFragmentCompat plus setPreferencesFromResource(...).
• Settings screens should now be fragment-based, not built directly around PreferenceActivity.
• Preference XML files are still used, but they are loaded inside the fragment lifecycle.
• Add the AndroidX preference dependency before migrating.
• This pattern fits modern Android navigation, theming, and lifecycle management much better than the deprecated approach.