I'm developing payment terminal simulator that acts as a standalone POS terminal. It works ok with chip contactless cards (it can communicate with them on proper protocol), initiate transaction, read data from them etc.
I also wanted to handle transactions done by Google Pay (POS terminals recognize Google Pay as normal contactless card - same protocol). But when I have one Android device with my POS terminal app running, and another Android device with Google Pay, when I touch both devices together, my POS app is minimized and "Touch to send beam" is shown. I would have expected that instead the onNewIntent method is called in the POS terminal app.
How to handle this? The expected behaviour is that my app (POS terminal) is not minimized, and on the other phone the Google Pay app is triggered.
Should I send something at the begginng, so that Android with Google Pay can recognize that this is a payment transaction? Or maybe some specific intent-filter to handle this on the POS terminal Android device?
I also observed that in one of three to four tries, I seem to get the expected behaviour - onNewIntent is called in my app. This looks like some race condition beetween my app and the default Android Beam behaviour.
You can't use the regular tag dispatch mechanisms (intent filter or foreground dispatch system) to interact with another Android device that operates in card emulation (HCE) mode. The problem is that the two Android devices will typically automatically discover their peer-to-peer mode capabilities. Hence, they connect in P2P mode and trigger Android Beam (SNEP on top of LLCP on top of P2P). Note that even if you disable Android Beam on both devices, they will still choose P2P mode.
To overcome this, you will need to use the reader mode API. This allows you to disable P2P mode and selectively enable reader/writer mode functionality (e.g. different technologies) while your activity is in the foreground.
Related
I have a Bluetooth LE Joystick with a couple of buttons. I want to connect it directly to the app without using the Bluetooth Settings, but by connecting to it via BluetoothLeScanner.
I already can connect to a Heart Rate Monitor and get periodic notifications of the HR-values.
I also have created a little temperature/light/humidity sensor with an ESP32 to which I can also connnect and display the sensor values in the app.
My understanding of this HID device may be erroneous. With the help of the App BLE Scanner I can connect to this gadget via BLE and see the offered services.
One of them is 0x1812 HUMAN INTERFACE DEVICE, which contains a couple of characteristics of type REPORT, among others which are described HID OVER GATT PROFILE SPECIFICATION (HOGP_SPEC)
How can I find out which button got pressed, what position the joystick has been moved to? I guess that this has to occur via notifications to which I have to subscribe to.
Is there any Android library avaliable to handle HID input devices? What I do NOT want to do is to use the Bluetooth settings and connect to the device and have it become detected as a HID device and replace the keyboard with some odd mapping. I don't want the OS to get involved at all, just like when I connect and use the HRM and the ESP32.
I couldn't find any information on this.
I can connect to the device with my app, enumerate the services and characteristics. But from there on, I have no clue how to work with HID. Ideally I'd get notifications like "Button A has been pressed" "Joystick got moved to x=32" where x would range from -127 to 127, for example.
Accessing the HID characteristics requires the BLUETOOTH_PRIVILEGED permission since Android 5.0. The only way for an app to obtain that permission is to be signed with the same certificates as system apps.
This is a security feature, to prevent an app from receiving HID events from your keyboard and stealing your passwords.
Quoting from https://devzone.nordicsemi.com/cfs-file/__key/communityserver-discussions-components-files/4/BLE_5F00_on_5F00_Android_5F00_v1.0.1.pdf
4.6 Protected services
Android does not allow to read or write data to the following characteristics (and their descriptors):
HID Service (since Android 5):
a. HID Information
b. Report Map
c. HID Control Point
d. Report
FIDO (https://fidoalliance.org/) (since Android 6)
a. U2F (0000FFFD-0000-1000-8000-00805F9B34FB)
Only applications with BLUETOOTH_PRIVILEGED, that is, applications signed
with the same certificate as the system, are able to read and write
data to those characteristics.
I have some questions about the communication between a NFC reader and an Android phone.
The first subject is the Android / NFC reader modus:
What is the best way to pass a unique identifier from the NFC reader (ACR122U) to an Android device? ACR122U in peer-to-peer, card emulation, or reader/writer mode? Wich modus are possible? And what is the best mode if you want bi-directional communication?
The second subject is about the listener on the android device:
How can a Android reader trigger an Android application? When you tap your phone on the NFC reader, do you need to have the Android application in the front or do you need to write a NFC listener or something while your application is running on the background?
Many thanks.
What is the best way to pass a unique identifier from the NFC reader (ACR122U) to an Android device?
That depends on what you want to achieve.
Using the ACR122U in reader/writer mode will basically limit you to using Android 4.4 and later (as Android HCE -- for putting the phone into host-based card emulation mode -- is only supported from 4.4 onwards).
Peer-to-peer mode will work but will effectively limit you to sending one data packet (or one message) into a single direction.
Using the ACR122U in card emulation mode will permit you to perform true bidirectional communication (i.e. to send multiple data packets into both direction).
See this answer for a list of further literature.
Which modes are possible?
All three modes are possible but give you different degrees of freedom.
And what is the best mode if you want bi-directional communication?
See above, using the ACR122U in card emulation mode and the phone in reader/writer mode will permit bi-directional communication on all Android versions. The phone has the role of the interrogator (in a command-response protocol) in this case.
If you only want/need to support Android 4.4 and later, you could just as well use the phone in HCE (host-based card emulation) mode and the ACR122U in reader/writer mode.
When you tap your phone on the NFC reader, do you need to have the Android application in the front or do you need to write a NFC listener or something while your application is running on the background?
If you are using Android HCE (phone as emulated card): In this case, the communication is handled by a background service. No user interface is needed on the device. If you want to start a user interface upon scanning the ACR122U with a phone, I suggest that you stick with using the Android in reader/writer or peer-to-peer mode (though you could start a UI through the HCE service too).
If you are using the Android in reader/writer mode: You need an app running in the foreground to communicate with an NFC tag/smartcard/emulated card. However, the
app can be started automatically upon detection of the tag. You would
use an intent filter that matches either the tag's technology or
(better yet) matches an NDEF record that is stored on the tag. See
this for further details.
Is it possible for an Android application to send a previously stored RFID card ID to a NFC reader? The aim would be to use an Android device to enable access to a room instead of a physical RFID card.
Having read a lot of other threads about NFC/RFID & card-emulation, I came to the conclusion it was not available for now in Android but I'm still kinda confused if it apply to this particular case. Can't the application simply send the card ID within a NDEF message or an APDU command or I'm just completely dreaming?
Well, strictly speaking. For what you want to do you don't need card emulation. You just need to send a token to the door lock that can be validated.
You could do this with Android beam by pushing an NDEF message to a device that is compatible, SNEP is the protocol you'll be looking for.
A solution I would prefer would be to get the door lock device to emulate a tag. Then you could have your Android app register a listener for that tag (Doesn't even need to be running). When the tag is detected that app will fire up and send your secure token to the lock by using the tag write NFC functions in the Android SDK.
Securing your token is another matter.
The android view:
Long story short: It's not possible.
Long story long:
It would be possible from a hardware and software point of view to do this. The NFC chips are perfectly capable to emulate most (not all) standard tags. The functionality to do this is even built in the lower level software but not exposed to applications.
Why: Emulating tags is what the entire mobile payment infrastructure is built upon. Allowing two card emulations of the same type at once is for most NFC chips not possible and will also shut off mobile payment as mobile payment readers only accept a single tag at once (for security reasons).
Things are a bit different for RIM based Blackberry phones, they allow card emulations (even have this feature out of the box) but they don't do any mobile payment at the moment as far as I know.
It is possible?
I state that NFC is enabled on my phone and everything looks correct
I tried with an app called NFC TagWriter by NXP but don't work.
I create a tag with this app and then I tried to listen with other device but don't work, then I installed same app on the other device but don't work.
Please help me or suggested to me another way to do(share tag NFC).
THANKS!
The Android Beam™ feature allows a device to push an NDEF message onto another device by physically tapping the devices together. This interaction provides an easier way to send data than other wireless technologies like Bluetooth, because with NFC, no manual device discovery or pairing is required. The connection is automatically started when two devices come into range. Android Beam is available through a set of NFC APIs, so any application can transmit information between devices. For example, the Contacts, Browser, and YouTube applications use Android Beam to share contacts, web pages, and videos with other devices.
Reference from Developer Documentation
Also check this for Blog , it explains how to communicate between devices.
You can have (indepedent) p2p communication in 2 directions, and enableForegroundNdefPush is deprecated now; please, use setNdefPushMessage
When an android device with NFC is in home screen (screen on of course, otherwise the NFC won't work), does it act as an NFC target? If so, what data does it show?
In other words, can I write an app for one phone that can identify other phones (without any propriety app)?
you can communicate with other NFC phone in the so-called NFC p2p mode (see the example here). In this case must be on both devices your application installed.
The other option for the device is to act as a NFC tag reader/writer - but this is not an option for your application, because in this mode phone communicates with the passive NFC tags.
The third option is to enable the phone to work in card emulation mode. In this mode phone mode emulates the contactless smart card. This is not possible with current Android OS version API and it is anyway intended only for e.g. banking and payment applications.
See http://developer.android.com/reference/android/nfc/Tag.html
First, if any app enabled foreground dispatch, those will get notified. In your case - it's at the home screen, so this does not applies.
Afterwards, it basically goes through the intents list to see if any app is interested at any tag.
In the other word, when the screen is on and at the home screen, the behavior is like you have QR code scanner always scanning for QR code, and Browser/Phone Contact/Whatever app when a corresponding code is scanned - except is this case it's about NFC tag, not QR code.
The phone never act as tag (passive device) except in specific payment mode (Google checkout) - aka card emulation mode. However, the API does not expose this mode for developer.