Android topics — 01: What survives rotation?

The ordinary field starts at 0 in the new Activity. The Bundle counter is restored to 1 during recreation. The preferences counter is read from storage and remains 1. Restoring state before rendering brings the correct values to the new Views.

View Binding generates a class containing direct references to the Views in an XML layout. You no longer need to find each component with findViewById. This makes the code shorter and catches ID or type errors earlier.

Step 1 — Enable View Binding in Gradle

Open build.gradle.kts (Module :app) under Gradle Scripts and add buildFeatures inside the existing android block. Keep your project’s current compile SDK configuration:

 android {
     namespace = "com.example.topics"
     ⁞
+    buildFeatures {
+        viewBinding = true
+    }
+
     defaultConfig {
         ...
     }
 }

The ⁞ and ... lines represent existing configuration omitted from this excerpt; do not type them into Gradle.

After editing, sync Gradle using the button.

Step 2 — Convert MainActivity to use Binding

Edit MainActivity.java:

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    EdgeToEdge.enable(this);

    setContentView(R.layout.activity_main);
    ViewCompat.setOnApplyWindowInsetsListener(findViewById(R.id.main), (v, insets) -> {
        Insets systemBars = insets.getInsets(WindowInsetsCompat.Type.systemBars());
        v.setPadding(systemBars.left, systemBars.top, systemBars.right, systemBars.bottom);
        return insets;
    });
}

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    EdgeToEdge.enable(this);
    binding = ActivityMainBinding.inflate(getLayoutInflater());
    setContentView(binding.getRoot());
    ViewCompat.setOnApplyWindowInsetsListener(binding.main, (v, insets) -> {
        Insets systemBars = insets.getInsets(WindowInsetsCompat.Type.systemBars());
        v.setPadding(systemBars.left, systemBars.top, systemBars.right, systemBars.bottom);
        return insets;
    });
}

The binding field is unresolved. Right-click it, choose Show Context Actions, and select Create field ‘binding’ in ‘MainActivity’:

This creates the field and adds the required import. Verify that the class contains:

import com.example.topics.databinding.ActivityMainBinding;

private ActivityMainBinding binding;

For another package, use that package’s generated databinding import.

Why this works: binding.getRoot() returns the layout’s root View. binding.main accesses the View with android:id="@+id/main", so findViewById is no longer necessary. The window-inset and padding logic stays unchanged.

The first three questions below come from the local English QuestionsAndAnswers.md for Android-Lifecycle, including its latest saved-state explanation. The upstream Q&A document is also available. The first three questions concern this lab; the last two concern the companion Fragments project. These excerpts explain existing code and are not additional implementation steps.

1. How does Back reattach the Fragment without an explicit attach() call?

Back reverses the transaction recorded by FragmentManager

The key is .addToBackStack("detached_view") in LifecycleFragment.onViewCreated() in LifecycleFragment.java:

binding.detachView.setOnClickListener(v -> getParentFragmentManager()
        .beginTransaction()
        .detach(this)
        .addToBackStack("detached_view")
        .commit());

This listener asks the fragment’s owning FragmentManager to detach this fragment and record the transaction on its back stack. commit() schedules the transaction to run. The string "detached_view" names the back-stack entry; it is not a method name or a callback.

When the user presses device Back, AndroidX’s built-in Back handling pops the top fragment transaction. Popping reverses its operations: the reverse of detach(this) is to attach that fragment again. The manager performs that operation internally, so this project does not need its own Back listener or an explicit attach() call. See the Android documentation on fragment back-stack handling and fragment transactions.

The experiment follows this sequence:

1. The fragment and its view are visible.
2. Destroy Fragment View runs the detach transaction. The view is destroyed, but the fragment object remains managed by FragmentManager.
3. onDestroyView() clears binding, releasing this fragment’s references to the old view tree.
4. Back pops the transaction and reverses the detach.
5. onCreateView() creates a new view tree and binding. onViewCreated() reconnects the listeners and calls renderCount().

The relevant cleanup in this project’s onDestroyView() is:

binding = null;
super.onDestroyView();

The new view is created in onCreateView():

binding = FragmentLifecycleBinding.inflate(inflater, container, false);
return binding.getRoot();

During a simple detach/Back cycle, with no activity recreation or process death, the same fragment object survives. Its count field therefore survives too. Clearing binding does not clear count; renderCount() displays that field through the new binding. The instance numbers logged by this class let you compare the fragment identity before and after the cycle.

If Android recreates the component, retaining the old Java object is no longer the explanation. This project also saves count in onSaveInstanceState() and reads it in onViewCreated() when a saved bundle is supplied.

Without addToBackStack(...), Back would not undo this detach automatically. Explicit reattachment would then require another transaction using attach(fragment). Also, the transaction operation detach() is distinct from the lifecycle callback onDetach(); destroying the fragment’s view does not mean destroying the fragment object or disconnecting it from its activity. See attaching and detaching fragments.

2. Is the XML declaration enough to display the Fragment?

XML declares the fragment, and MainActivity inflates and displays the layout

There is no explicit fragment-add transaction in MainActivity.java. The declaration in activity_main.xml selects the fragment class and its container:

<androidx.fragment.app.FragmentContainerView
    android:id="@+id/lifecycle_fragment"
    android:name="com.example.topics.LifecycleFragment"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:layout_marginTop="32dp" />

android:name is the important part for automatic fragment creation. A FragmentContainerView without that attribute supplies a container, but does not select a fragment to instantiate. The ID identifies the container. AndroidX adds the declared fragment during layout inflation, or uses the fragment restored by its manager when applicable. See adding a fragment using XML.

The XML still needs to be loaded by a fragment-capable activity. This project’s activity extends AppCompatActivity, which inherits AndroidX fragment support, and its onCreate() calls:

super.onCreate(savedInstanceState);
EdgeToEdge.enable(this);
binding = ActivityMainBinding.inflate(getLayoutInflater());
setContentView(binding.getRoot());

Here, ActivityMainBinding is generated from activity_main.xml because View Binding is enabled in app/build.gradle.kts. inflate(...) builds that layout, including the FragmentContainerView. setContentView(...) installs the resulting root as the activity’s screen. The superclass supplies the fragment infrastructure and restoration handling.

The fragment then supplies its own UI through LifecycleFragment.onCreateView(). That method inflates fragment_lifecycle.xml using FragmentLifecycleBinding and returns the root. The false argument to its inflate(...) call leaves attachment of that root to FragmentManager.

So the XML declaration is sufficient to specify and automatically add this fragment within the existing activity setup. The Java code is still necessary to host fragments and load/display the activity layout, but it does not need an additional add() or attach() transaction. The counter listeners, edge-to-edge setup, and window-inset listener do not select or add the fragment.

If you removed android:name, you would need to add the fragment through code instead. That alternative should normally add it only on a fresh creation (savedInstanceState == null), allowing the manager to restore it on recreation. It is an alternative to this project’s XML declaration, not an extra step required by the current code.

3. Who calls onSaveInstanceState(), and how does the Bundle reach the new instance?

Android requests a snapshot, your code fills it, and Android supplies it during restoration

Android calls the activity’s onSaveInstanceState(Bundle outState) through its lifecycle machinery. You override this callback to contribute your state; the button listeners do not call it. Android supplies outState, your method writes values into it, and Android retains the resulting saved state for possible recreation. See saving activity instance state.

In MainActivity.java, the callback is:

@Override
protected void onSaveInstanceState(Bundle outState) {
    outState.putInt(SAVED_COUNT, savedCount);
    super.onSaveInstanceState(outState);
}

SAVED_COUNT is the key "saved_count". If savedCount is 2 when the callback runs, putInt(...) puts that number into the supplied bundle under that key. It does not save the activity object, the binding, or every field automatically.

super.onSaveInstanceState(outState) lets the inherited Android/AndroidX implementation contribute framework state, including supported view state and fragment-manager state. It is part of completing the save operation, rather than calling your override again.

For this project’s Android versions (minimum API 31), a normal rotation that recreates the activity follows this activity callback sequence:

Old MainActivity:
    onPause()
    onStop()
    onSaveInstanceState(outState)   <-- copy savedCount into the snapshot
    onDestroy()

New MainActivity:
    onCreate(savedInstanceState)   <-- read savedCount from the snapshot
    onStart()
    onRestoreInstanceState(...)    <-- inherited restoration; no override here
    onResume()

For apps targeting API 28 or later, onSaveInstanceState() occurs after onStop() when it is invoked. Older targeting rules differ. This is a rotation example, not a promise that every pause, stop, or destruction invokes saving. See the Activity callback reference.

The new activity reads the saved value in this project’s onCreate():

if (savedInstanceState != null) {
    savedCount = savedInstanceState.getInt(SAVED_COUNT);
}

outState means the outgoing snapshot being filled; savedInstanceState means the incoming saved state being read. These are parameter names, not two storage services. Restoration preserves the saved values; it does not require the exact same Java Bundle object to survive.

That explains this project’s rotation result after two increments: memoryCount starts at 0 in the new activity because the code never saves it, savedCount becomes 2 from the bundle, and persistentCount becomes 2 by reading SharedPreferences. renderCounts() then displays those fields.

The fragment’s snapshot is coordinated by AndroidX FragmentManager as part of saving the host activity. It calls the fragment’s onSaveInstanceState() and includes that fragment’s saved state within the manager’s state. The activity and fragment receive their own state bundles; they do not share one flat collection of custom keys. See saving state with fragments.

In LifecycleFragment.java, the fragment contributes its own counter:

@Override
public void onSaveInstanceState(@NonNull Bundle outState) {
    outState.putInt(SAVED_COUNT, count);
    super.onSaveInstanceState(outState);
}

Here, SAVED_COUNT means "fragment_count". On restoration, the manager supplies this fragment’s saved bundle to its creation callbacks. This project reads the counter in onViewCreated():

if (savedInstanceState != null) {
    count = savedInstanceState.getInt(SAVED_COUNT);
}

The activity does not manually call the fragment’s save method or forward its own bundle to the fragment. Also, the earlier detach/Back experiment can retain count in the surviving fragment object without needing a fresh saved-state callback just because its view was destroyed.

The bundle is a small restoration snapshot, not a file your code writes or permanent app storage. Android keeps saved state outside the app process so it can restore a retained task after system-initiated process death. The snapshot must already have been collected; killing a process does not give the app a final opportunity to run this callback. Finishing the activity, force stopping, or dismissing the task is not a durable-storage use case. Use persistent storage for values that must survive those actions. See saved state and persistence.

In this demo, the persistent counter is written separately on every increment:

preferences.edit().putInt(PERSISTENT_COUNT, persistentCount).apply();

So there are two distinct triggers in the code: an increment changes the fields and requests a preferences write immediately; an Android save request copies the current savedCount and fragment count into restoration bundles later.

Check your understanding: after two increments, the counters display 2, but no new save request has occurred yet. Which line will put 2 into the Bundle when the callback arrives? Does killing the process now guarantee restoration of the latest value? Explain using the time at which the snapshot is collected.

4. How does the Fragments project display and switch screens?

MainActivity places one of three Fragments in an empty container. The Fragments activity_main.xml contains a FragmentContainerView with the ID fragment_container and a bottom navigation bar. The container has no android:name, so MainActivity.java chooses the Fragment in code.

After loading the Activity layout, onCreate() connects the navigation listener and chooses Home on first creation:

binding.navView.setOnItemSelectedListener(item -> showFragment(item.getItemId()));
if (savedInstanceState == null) {
    showFragment(R.id.navigation_home);
}

showFragment(...) maps the Home, Dashboard, and Notifications menu IDs to new HomeFragment(), new DashboardFragment(), and new NotificationsFragment(). It then checks the class of the Fragment currently displayed in the container, replacing the screen only when the container is empty or the classes differ:

Fragment current = getSupportFragmentManager()
        .findFragmentById(R.id.fragment_container);
if (current == null || current.getClass() != fragment.getClass()) {
    getSupportFragmentManager().beginTransaction()
            .setReorderingAllowed(true)
            .replace(R.id.fragment_container, fragment)
            .commit();
}

getSupportFragmentManager() accesses the manager from the Activity. setReorderingAllowed(true) lets it coordinate the transaction’s state and lifecycle changes. replace(...) removes the current Fragment from the container and adds the selected one; commit() schedules execution. Selecting the already displayed screen does not replace it. Switching to another screen and then returning creates a new Fragment; this implementation does not retain a separate instance for each tab.

The savedInstanceState == null condition avoids selecting Home again during Activity recreation and lets FragmentManager restore the previously displayed Fragment.

5. Why do the example classes have no onCreateView(), and does Back undo a tab change?

Each Fragment passes its layout to the superclass; tab replacements are not recorded on the back stack. Each of the three classes has only a public no-argument constructor passing its layout resource to Fragment. For example, HomeFragment.java:

public class HomeFragment extends Fragment {
    public HomeFragment() {
        super(R.layout.fragment_home);
    }
}

The inherited onCreateView() implementation inflates that layout. Dashboard and Notifications use the same pattern with fragment_dashboard and fragment_notifications. Their layouts display simple screen labels, so the classes do not need View Binding or button listeners. In contrast, LifecycleFragment overrides onCreateView() to create a binding for its interactive View and clears it in onDestroyView().

The replacement transactions in the Fragments project do not call addToBackStack(...), so Back does not return to the previous tab. These are three peer screens selected through the navigation bar. In the lifecycle lab, we deliberately record detach(this) on the stack, so Back reverses the detach and recreates the View of the same managed Fragment.

Test the distinction: in the lifecycle lab, increment the counter, detach the View, and return with Back. In the Fragments project, switch from Home to Dashboard and press Back. Before running, predict which experiment will reverse its transaction, and identify the code call responsible.