Initial requestTechnology works but subsequent write attempts fail. Android 16, Samsung S24 ultra

[999SH]

When launching the app and using requestTechnology(NfcV) on android, I get NfcV as a response from this code:

try { const response = await NfcManager.requestTechnology( [NfcTech.NfcV, NfcTech.Ndef], { alertMessage: systemPrompt, } )

also tested:

const response = await NfcManager.requestTechnology(NFC_TECH, { alertMessage: systemPrompt, isReaderModeEnabled: true, readerModeDelay: 0, readerModeFlags: NfcAdapter.FLAG_READER_NFC_V | NfcAdapter.FLAG_READER_SKIP_NDEF_CHECK | NfcAdapter.FLAG_READER_NO_PLATFORM_SOUNDS, })

And I open the session with:

await NfcManager.registerTagEvent({ isReaderModeEnabled: true, /* tested both with and without */ readerModeFlags: NfcAdapter.FLAG_READER_NFC_V | NfcAdapter.FLAG_READER_SKIP_NDEF_CHECK | NfcAdapter.FLAG_READER_NO_PLATFORM_SOUNDS, readerModeDelay: 0, })

const response = await NfcManager.nfcVHandler.transceive(modifiedBytes)

I then run this in the finally, which runs fine with no error:

finally { await NfcManager.cancelTechnologyRequest({ throwOnError: true }) }

but the next time I try to requestTechnology, I get null instead of NfcV (despite waiting 10s, removing the tag from scanning distance, etc). But I do get a log response from my native intent before the requestTechnology runs. My analysis of the situation is that the android background NFC reader somehow gains priority, even when we are actively attempting to write to the tag. When I attempt to open another session after it returns null, I get that I can only have one session open at a time, which implies that the previous session is closed and maybe cleared, although probably not correctly. Why could this be happening?

nativeIntent: export async function redirectSystemPath({ path, }: { path: string initial: boolean }): Promise<Href | null> { } else if (path.startsWith('https:// /* Tag content */ ')) { const result = await parseNfcUrl(path) console.log('parsed nfc url from redirectSystemPath') }

return path as Href }

Version: "react-native-nfc-manager": "^3.16.2", also surface level tested on 3.17.1 with the same issue

EDIT:

Appears to be related to the android manifest. If I strip away all forms of nfc discovery from the manifest then it becomes a whole lot more consistent and responsive:

'android.nfc.action.NDEF_DISCOVERED', 'android.nfc.action.TECH_DISCOVERED', 'android.nfc.action.TAG_DISCOVERED', 'android.intent.action.NDEF_DISCOVERED',

It is very possible that the error happens either earlier, during the opening of the session, or it might be something to do with the manifest configuration of this project. Or it might just be android behavior, which has to be disabled somehow.

Further debugging, I think this might be related to the state machine of the ISO15693/NfcV chip, it happens when a write is cancelled and im guessing the tag does not get enough power to finish the operations and go back to a writeable state. The issue resolves if I read it a couple of times and restart my app

Final edit:

It appears to be a bug with the samsung nfc service, workaround found here:

https://forum.developer.samsung.com/t/one-ui-v8-update-causing-nfc-readermode-to-crash-low-level-driver/42606/8

[PsukheDelos]

I wonder if this is at all related to this change in Android 16 per the Android developer docs here: https://developer.android.com/develop/connectivity/nfc/nfc#dispatching

Note: Starting Android 16, scanning NFC tags that store URL links (i.e URI scheme is "https://" or "http://") will trigger the ACTION_VIEW intent instead of ACTION_NDEF_DISCOVERED intent.

[999SH]

@PsukheDelos ive debugged with adb and it appears that the nfc service crashes after an initial read. It appears to be a samsung bug, this seems to be the exact same issue, with a confirmation from samsung.

https://forum.developer.samsung.com/t/one-ui-v8-update-causing-nfc-readermode-to-crash-low-level-driver/42606/8

[PsukheDelos]

Cheers @999SH that's really helpful. Thank you. That is exactly what we're seeing as well.

[tastydev]

According to the users it has been fixed by samsung by the latest OneUI update.

[999SH]

Appears to be fixed by samsung!