The HCI Event Transaction message from the NFC terminal does not seem to always get posted to the upper layers from nfcd, even as messages like the following are posted: D/NfcNci ( 308): notifyRfFieldEvent: enter; is active=0 D/NfcNci ( 308): notifyRfFieldEvent: enter; is active=1 There doesn't seem to be a specific pattern. Some possible steps to reproduce (Flame dev phone, with special app already installed on the SIM card/Secure Element): Enable NFC in the gaia profile: build/config/common-settings.json --> nfc.enabled --> true - Setup the Terminal Simulator, and payment amount. - Put the phone on top of the NFC/NXP reader. - Flash the phone. - Observe that while the payment goes through, the console doesn't necessarily show the transaction message is posted. - If it fails, start a new payment. - Reboot the phone, without doing anything else. - Transaction might get posted through to the txn enabled Gaia app. The same can happen even if the phone is not flashed while on the reader. Timing bug?
Hi Garner, I am not sure if you mean you have to flash device every time. So I use following reproduce step but i can not reproduce it, could you help check if there is any thing wrong ? Precondition: 1. NFC ON 2. Disable Screen lock 3. Flame device always put on the card reader. Reproduce step: 1.sudo adb reboot 2.After device reboot, use POS software to trigger EVT_TRANSACTION, if success, repeat step1 and 2. BTW,If you can reproduce it, could you attach the log for me ? thanks
I'll do some more investigation with the POS outside on a real windows machine to eliminate possible VM USB issues. Head revision flame adb log is posted in the mean time (last instance in log failed. No reboots were taken).
Hi Garner, From the attach adb.log, I saw there are many HCI events fired and for each event HCI Event Demo application did receive the EVT_TRANSACTION message, but the payload is quite slow. I am not sure if the payload is correct or there is any HCI event triggered but there is no message in this log.
I switched over to flame-kk repos (may have to go back for SE). It is working better on a non Virtual windows box (as far as detection goes), and only a bit less reliable against a VM. I'll keep it open for a few more days just in case, and close as not reproducible.
Closing as worksforme on a clean workspace. Build env issues most likely on the old workspace. I don't see the problem on a clean config.sh flame|flame-kk pull.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.