[Android] No autofill session is ever started for TextInputs on a pushed screen

[tomKFM]

Description

On Android, a TextInput that lives on a screen pushed onto a native stack never gets an autofill session. The platform does not merely fail to show a suggestion: it never sends a FillRequest to the autofill service at all, so no password manager can offer credentials, and no "save password" prompt appears after a successful sign-in.

The same TextInput, with the same props, works normally on the stack's initial route. That is the whole difference.

This is what makes it hard to spot from the app side: the fields are correctly annotated, the accessibility tree is correct, the keyboard opens, and nothing is logged. The framework simply never asks.

Verified with two different autofill services (Bitwarden and Google's), so this is not service-specific. Measured with adb shell dumpsys autofill, section Requests history:

Screen	FillRequest recorded
initial route of the stack	yes, immediately on focus
route pushed onto the same stack	none, ever

A native Android app on the same emulator, with the same service, records a request instantly, so the device and the service are working.

Expected: focusing an autofillable TextInput starts an autofill session, wherever the screen sits in the navigation stack.

Things that do not change the outcome

• importantForAutofill="yes" on the field.
• Backgrounding then foregrounding the app. This differs from [Android] TextInput autofill fails but works after background/foreground cycle - regression of #349 #3130, where that cycle was reported to unblock autofill.
• Removing the stack animation (animation: "none" and the default are both affected).
• A custom header versus headerShown: false.
• Debug build versus release build.
• Which autofill service is installed.

What does change it

Replacing <Stack> with expo-router's <Slot>, which builds its navigation with the same StackRouter but renders only the focused route, without the native screen container. Autofill then works on every screen. That is the workaround we shipped, and it is only viable because those screens needed no stack animation.

Hypothesis

Offered as a hypothesis, not a claim, since I have not instrumented the native side.

View.notifyEnterOrExitForAutoFillIfNeeded defers the autofill notification to the next View.layout() when isLaidOut() is false, setting PFLAG3_NOTIFY_AUTOFILL_ENTER_ON_LAYOUT instead of calling AutofillManager.notifyViewEntered. For a pushed screen, the subtree appears to be mounted and laid out by the Fabric mount batch before the fragment transaction attaches it, and View.onAttachedToWindow clears that laid-out flag. React Native never lays out a view again when its frame has not changed, so the deferred notification never fires.

That would explain why the initial route is unaffected: its fragment is attached before the first layout, not after it.

Steps to reproduce

1. Create a blank Expo SDK 54 app and add expo-router.
2. Use the three files below.
3. npx expo prebuild --platform android and build a release APK.
4. Install a password manager (Bitwarden works) and set it as the system autofill service, or use Google's.
5. Launch the app. On the initial screen, focus a field. adb shell dumpsys autofill shows a new line under Requests history.
6. Tap "Go to sign in" to push the second screen. Focus the username field.
7. adb shell dumpsys autofill shows no new line. No suggestion appears above the keyboard.

To see the contrast in one run, put a TextInput on both screens.

app/_layout.tsx

import { Stack } from "expo-router";

export default function RootLayout() {
  return <Stack />;
}

app/index.tsx

import { Link } from "expo-router";
import { Text, View } from "react-native";

export default function Index() {
  return (
    <View style={{ flex: 1, justifyContent: "center", alignItems: "center", gap: 24 }}>
      <Text style={{ fontSize: 20 }}>Autofill repro</Text>
      <Link href="/login" style={{ fontSize: 18, color: "#06c", padding: 16 }}>
        Go to sign in
      </Link>
    </View>
  );
}

app/login.tsx

import { useState } from "react";
import { StyleSheet, Text, TextInput, View } from "react-native";

export default function Login() {
  const [username, setUsername] = useState("");
  const [password, setPassword] = useState("");

  return (
    <View style={styles.page}>
      <Text style={styles.h1}>Sign in</Text>
      <TextInput
        style={styles.input}
        value={username}
        onChangeText={setUsername}
        placeholder="username"
        autoComplete="username"
        autoCapitalize="none"
        autoCorrect={false}
      />
      <TextInput
        style={styles.input}
        value={password}
        onChangeText={setPassword}
        placeholder="password"
        secureTextEntry
        autoComplete="password"
        autoCapitalize="none"
        autoCorrect={false}
      />
    </View>
  );
}

const styles = StyleSheet.create({
  page: { flex: 1, paddingTop: 120, paddingHorizontal: 20, gap: 16, backgroundColor: "#fff" },
  h1: { fontSize: 22, fontWeight: "700", marginBottom: 12 },
  input: { borderWidth: 1, borderColor: "#bbb", borderRadius: 8, paddingHorizontal: 12, height: 48, fontSize: 16 },
});

Snack or a link to a repository

https://github.com/tomKFM/rn-screens-android-autofill-repro

Screens version

4.16.0

React Native version

0.81.5

Platforms

Android

JavaScript runtime

Hermes

Workflow

Expo bare workflow

Build type

Release mode

Device

Android emulator

Device model

Pixel emulator, Android 17 (API 37), also seen on a production build on physical devices

Acknowledgements

Yes

Related

• Android - TextInput Autofill not working  #349, open since 2020, same symptom, no reproducer that isolates the pushed screen.
• [Android] TextInput autofill fails but works after background/foreground cycle - regression of #349 #3130, reported as a regression of Android - TextInput Autofill not working  #349. The background and foreground cycle described there does not help in this case.

[kkafar]

Hey, thanks for the report.

The description you give seems plausible, together with the hypothesis.

And it indeed seems that our Fragment setup is partially responsible for inversion of actions (view hierarchy assembly, layout) together with the fact, that ReactViewGroup (View and most of custom native components) does not take part in native layout flow, which IS triggered after fragment is attached to window.

After giving it a few first thoughts I don't have a good solution in mind. We'll first reproduce it and then start researching what we can do about this.

[jason-cooper-ih]

We hit this in production (RN 0.81.1, react-native-screens 4.16.0, Fabric, Android 14/15, Samsung + Pixel) and can confirm the mechanism @tomKFM proposed, with the platform source and a fix that works. Posting in case it saves someone the week it cost us.

Note: it is not limited to the native stack. Our app uses @react-navigation/stack (the JS stack). It mounts screens in ScreenContainer fragments too, so it hits the same thing.

Mechanism, confirmed against AOSP View.java (android14-release)

• notifyEnterOrExitForAutoFillIfNeeded() will not call AutofillManager.notifyViewEntered() unless isLaidOut() && isVisibleToUser(); otherwise it sets PFLAG3_NOTIFY_AUTOFILL_ENTER_ON_LAYOUT and waits for the next layout() (View.java:8383-8384). No enter → no session → no FillRequest, which is exactly what dumpsys autofill shows.
• onAttachedToWindow() clears PFLAG3_IS_LAID_OUT (View.java:21421). Only layout() sets it again (:24450), and layout() is also where the deferred enter is consumed (:24481-24483).
• Under Fabric, the mount batch runs measure()/layout() on the new screen's entire subtree before the Screen is attached: when a Screen is added to a ScreenContainer that is already on screen, addScreen only records it, and onScreenChanged() defers the fragment commit via reactApplicationContext.runOnUiQueueThread { performUpdates() } (ScreenContainer.kt:334-350, a Handler.post), so commitNowAllowingStateLoss() (:423) runs after the batch. The attach cascade then clears the flag on every view it just attached, and nothing lays them out again — RN only re-sends UpdateLayout when a frame changes, and the React view groups' onLayout does not lay out children.
• Result: the EditText is attached, sized, hinted, visible — and isLaidOut() == false. The platform waits forever.

This is also why the background/foreground cycle in #3130 "fixes" it (something triggers a layout() on resume, which flushes the deferred enter) — we reproduced exactly that on a Samsung S24 Ultra with 1Password: nothing on the first tap, recent-apps and back, chip on the next tap. It also predicts that a true cold start works (the container attaches synchronously via onAttachedToWindow → performUpdatesNow, before the batch's layout phase), which matches "the same input on the initial route works" above. The #3130 variant where the EditText is absent from the AssistStructure has the same root: ViewGroup.dispatchProvideAutofillStructure drops the children of a not-laid-out container.

A fix that works for us

Re-run a same-frame layout() on every React-managed view under the Screen the moment its fragment view attaches. With an unchanged frame, layout() runs no onLayout and no listeners (setFrame returns false); it sets the flag and flushes the deferred enter if the field was already focused. It is a no-op on a cold start (views have width 0 at that point). We do it app-side with a recursive FragmentLifecycleCallbacks so nested navigators are covered; the library-side equivalent would sit in ScreenContainer right after the commit attaches the fragment (or in onViewAdded, which ViewGroup.addViewInner dispatches after the attach cascade).

class ScreenAttachRelayout : FragmentManager.FragmentLifecycleCallbacks() {
    override fun onFragmentViewCreated(fm: FragmentManager, f: Fragment, v: View, s: Bundle?) {
        if (v.isAttachedToWindow) relayoutReactSubtree(v)
        else v.addOnAttachStateChangeListener(object : View.OnAttachStateChangeListener {
            override fun onViewAttachedToWindow(view: View) {
                view.removeOnAttachStateChangeListener(this); relayoutReactSubtree(view)
            }
            override fun onViewDetachedFromWindow(view: View) = Unit
        })
    }

    private fun isReactManaged(v: View) = v.id > 0 && (v.id ushr 24) == 0  // react tags, not resource ids

    private fun relayoutReactSubtree(root: View) {
        val stack = ArrayDeque<View>().apply { addLast(root) }
        while (stack.isNotEmpty()) {
            val v = stack.removeLast()
            if (v !== root && v !is Screen && v.parent !is ScreenContainer &&
                isReactManaged(v) && v.isAttachedToWindow && !v.isLaidOut &&
                v.visibility == View.VISIBLE && v.width > 0 && v.height > 0
            ) {
                v.layout(v.left, v.top, v.right, v.bottom)
            }
            if (v is ViewGroup) for (i in 0 until v.childCount) stack.addLast(v.getChildAt(i))
        }
    }
}

// MainActivity.onCreate:
supportFragmentManager.registerFragmentLifecycleCallbacks(ScreenAttachRelayout(), true)

Honest status: the mechanism above is verified against the platform source and the pre-fix fingerprint is measured on device; the fix itself compiles against 4.16.0 / RN 0.81.1 and is merged in our app, going out in our next tester build. I'll report the on-device result here (first tap on a sign-in field after sign-out, no background/foreground cycle) and the poison control (registration line removed → symptom back) once it's in hand.

Happy to turn this into a PR against ScreenContainer with an apps/src/tests/issue-tests screen if that's the shape you'd want — say the word.

[jason-cooper-ih]

Follow-up as promised: on-device result is positive.

Samsung S24 Ultra, 1Password 8, a build carrying the ScreenAttachRelayout hook above (RN 0.81.1 / react-native-screens 4.16.0 / Fabric, @react-navigation/stack): sign in → sign out → tap the email field once → the 1Password suggestion chip appears on that first tap, no background/foreground cycle. Same device, same steps, on the build before the hook: nothing.

Not yet measured, so not claimed: the poison control (registration line removed on an otherwise identical build → symptom returns). The before/after across builds is the evidence in hand.

The offer stands — happy to put this into ScreenContainer as a PR with an issue-tests screen if that's the shape you'd take.