在 Android 上持續檢測 NFC 標簽

Question

從我的閱讀和實驗中，我發現 Android 設備使用某種方法來防止重復讀取標簽（ 如此處所述）。 這對節能非常有用，但限制了該技術的可能應用。

例如，我面臨的問題是，我有一個內容不斷更新的被動標簽。 一旦標簽被讀取，手機將停止檢測標簽，直到它被移除，在此期間，如果不將其從字段中移除並重新點擊，您將無法繼續讀取標簽中的更新內容。 此外，在最初讀取標簽后，磁場或者關閉極弱以節省電力。 因此，您無法持續為無源設備供電。

有沒有辦法強制 Android 設備持續供電並讀取更新的被動標簽？

注意：我不介意它是否涉及對 Android 設備進行 root 以實現對硬件的直接控制。

Answer 1

您在問題中陳述的內容對於 Android NFC 設備完全不正確。 一旦檢測到標簽（= 響應所有強制性命令的有效標簽，並可能被發送到應用程序），NFC 閱讀器將持續為標簽供電（HF 載波保持開啟）並與其交換一些命令。 在保持活動階段（“存在檢查”）期間交換的命令取決於標簽類型、Android 版本和 Android NFC 堆棧實現。 這通常是

1. 重復停用和重新激活循環，
2. 重復讀取某個內存區域，或
3. 其他一些乒乓命令序列

這允許 NFC 堆棧確定標簽是否仍然響應。 僅當存在檢查失敗時，Android 才會關閉 NFC 閱讀器的 HF 載波，並以完整的輪詢序列（測試各種支持的標簽技術）或感測階段（短 HF 載波脈沖到檢測指示標簽潛在存在的失諧）。

因此，如果您的標簽行為正常並且您的用戶設法將標簽附加到 Android 設備上更長時間，則沒有什么可以阻止您多次從同一標簽（連續附加時）讀取新數據。 只要您想訪問標簽，並且您的應用程序的標簽讀取活動需要持續保持，您只需要確保保留標簽句柄（ Tag對象，甚至是從該標簽句柄實例化的特定標簽技術對象）在前台。

例如，您可以執行類似的操作以從標簽中讀取持續更新的 NDEF 消息（請注意，您可能最好使用AsyncTask （或類似的）而不是簡單地生成該線程，並且您可能希望實現某種機制來中斷線程）：

new Thread(new Runnable() {
    public void run() {
        Ndef ndef = Ndef.get(tag);

        try {
            while (true) {
                try {
                    Thread.sleep(30000);

                    ndef.connect();
                    NdefMessage msg = ndef.getNdefMessage();

                    // TODO: do something

                } catch (IOException e) {
                    // if the tag is gone we might want to end the thread:
                    break;
                } finally {
                    try {
                        ndef.close();
                    } catch (Exception e) {}
                }
            }
        } catch (InterruptedException e) {
        }
    }
}).start();

Answer 2

邁克爾的精彩回答。 但我看到了一個問題。 當標簽上的微控制器對 NFC 設備中的非易失性存儲器執行 i2c 讀取時，它似乎有干擾電話正在執行的“ping”的風險。

我使用的是摩托羅拉 G6 Play 手機，它與帶有 M24LR04E-R 的 M24LR-DISCOVERY 標簽非常相似。 [我已經復制了 ST25DV 的結果。] 該標簽由工作台電源供電，而不是來自該實驗的能量收集。

當標簽在手機的字段中時，我可以每 130 毫秒左右在 Android 調試器的 logcat 中看到活動。

2020-10-13 19:38:50.555 4209-4411/? I/libnfc_nci: [INFO:NativeNfcManager.cpp(793)] nfaConnectionCallback: Connection Event = 15
2020-10-13 19:38:50.555 4209-4411/? I/libnfc_nci: [INFO:NativeNfcManager.cpp(1389)] nfaConnectionCallback: NFA_PRESENCE_CHECK_EVT
2020-10-13 19:38:50.680 4209-28960/? I/libnfc_nci: [INFO:NativeNfcTag.cpp(1953)] nativeNfcTag_doPresenceCheck
2020-10-13 19:38:50.680 4209-28960/? I/libnfc_nci: [INFO:NativeNfcTag.cpp(1997)] nativeNfcTag_doPresenceCheck: handle=0
2020-10-13 19:38:50.694 4209-4411/? I/libnfc_nci: [INFO:NativeNfcManager.cpp(793)] nfaConnectionCallback: Connection Event = 15
2020-10-13 19:38:50.694 4209-4411/? I/libnfc_nci: [INFO:NativeNfcManager.cpp(1389)] nfaConnectionCallback: NFA_PRESENCE_CHECK_EVT
2020-10-13 19:38:50.820 4209-28960/? I/libnfc_nci: [INFO:NativeNfcTag.cpp(1953)] nativeNfcTag_doPresenceCheck
2020-10-13 19:38:50.820 4209-28960/? I/libnfc_nci: [INFO:NativeNfcTag.cpp(1997)] nativeNfcTag_doPresenceCheck: handle=0

這似乎是 Android 檢查標簽的存在。 在此期間，我看到 M24LR 的 RF_BUSY 輸出每 130 毫秒左右變低約 15 毫秒。 我將此與上面的 Android 活動相關聯。

如果微控制器隨后通過 M24LR 存儲器的 i2c 讀取塊，那么不久之后手機就會播放通知音。 發生的事情是手機與標簽失去連接並重新連接。 這次的 logcat 輸出顯示了這種情況而沒有警告。

2020-10-13 19:38:51.335 4209-4411/? I/libnfc_nci: [INFO:NativeNfcManager.cpp(793)] nfaConnectionCallback: Connection Event = 15
2020-10-13 19:38:51.335 4209-4411/? I/libnfc_nci: [INFO:NativeNfcManager.cpp(1389)] nfaConnectionCallback: NFA_PRESENCE_CHECK_EVT
2020-10-13 19:38:51.335 4209-28960/? I/libnfc_nci: [INFO:NativeNfcTag.cpp(2173)] nativeNfcTag_doPresenceCheck: tag absent
2020-10-13 19:38:51.335 4209-28960/? D/NativeNfcTag: Tag lost, restarting polling loop
2020-10-13 19:38:51.335 4209-28960/? I/libnfc_nci: [INFO:NativeNfcTag.cpp(1392)] nativeNfcTag_doDisconnect: enter
2020-10-13 19:38:51.335 4209-28960/? I/libnfc_nci: [INFO:NativeNfcTag.cpp(1414)] nativeNfcTag_doDisconnect: exit
2020-10-13 19:38:51.336 4209-28960/? D/NfcService: Discovery configuration equal, not updating.
2020-10-13 19:38:51.336 4209-28960/? D/NativeNfcTag: Stopping background presence check
2020-10-13 19:38:51.344 4209-4411/? I/libnfc_nci: [INFO:NativeNfcManager.cpp(793)] nfaConnectionCallback: Connection Event = 6
2020-10-13 19:38:51.344 4209-4411/? I/libnfc_nci: [INFO:NativeNfcManager.cpp(1121)] nfaConnectionCallback: NFA_DEACTIVATED_EVT: Type=0, gIsTagDeactivating=0
2020-10-13 19:38:51.344 4209-4411/? I/libnfc_nci: [INFO:NativeNfcManager.cpp(5280)] notifyPollingEventwhileNfcOff: sDiscCmdwhleNfcOff=0
2020-10-13 19:38:51.344 4209-4411/? I/libnfc_nci: [INFO:NativeNfcTag.cpp(921)] getReconnectState = 0x0
2020-10-13 19:38:51.345 4209-4411/? I/libnfc_nci: [INFO:NfcTag.cpp(189)] NfcTag::setDeactivationState: state=0
2020-10-13 19:38:51.345 4209-4411/? I/libnfc_nci: [INFO:NfcTag.cpp(1358)] NfcTag::resetTechnologies
2020-10-13 19:38:51.345 4209-4411/? I/libnfc_nci: [INFO:NativeNfcTag.cpp(263)] nativeNfcTag_abortWaits

斷開連接顯然會對手機上運行的任何試圖與標簽交換信息的應用程序造成嚴重破壞。

我嘗試使用 BUSY 信號來防止標簽上的微控制器在 RF 訪問正在進行時啟動任何 i2c 讀取操作，但問題仍然存在。 我猜這個問題是由於在進行內存訪問時發生了 RF ping，但我只是猜測。

似乎斷開連接的機會隨着讀取的字節數增加（支持“沖突”的想法）。單字節讀取通常可以逃脫而不會導致斷開連接。

這真的是正確的行為嗎？ 有什么辦法可以防止這種情況發生嗎？ OP（或我自己）將如何使用這些設備來實現一個系統，使標簽上的微控制器可以讀/寫 NFC 設備的內存，以便與手機上運行的應用程序交換信息？ 正如我所說，我在 M24LR 和 ST25DV 上都觀察到了這一點。

[抱歉，如果這更像是一個問題而不是答案，但我想對這個主題有更多的了解。]