I'm experimenting problems between my NFC reader and my NFC Smarthphone (I am using Host-based Card Emulation). The problem is the following...
My android application is able to receive the APDU to select the AID and I am able to return a result for the reader.
After that, I try to send a specific command to reader and get the response. I receive the call in my override method processCommandApdu and when It return the result, I receive an event in onDeactivated method which reason is DEACTIVATION_LINK_LOSS (my phone is very close of the reader).
Have you any idea about it?
Background: Commands are always initiated by the terminal. Your processCommandApdu() method is there to take that command the terminal sends, and then send back a response in the format that the terminal requires. It depends on what type of application you are creating and what kind of terminal you are using for development.
Answer: [DEACTIVATION_LINK_LOSS] happens when the terminal is done sending commands out and the NFC connection between the device and the terminal is terminated. This has nothing to do with the fact that your phone is close or not, this only has to do with the fact that the terminal is done with it's communication and the connection between the device is no longer there.
Documentation:
https://developer.android.com/reference/android/nfc/cardemulation/HostApduService.html#DEACTIVATION_LINK_LOSS
Related
I'm developing an adaptation for an android app, to communicate with a remote control, which has some pre defined commands.
I've followed this implementation to do the Bluetooth communication and it's working fine for sometime.
This app should communicate with the remote control every 5 minutes or less, and I've been using the app for almost 6 months now. The last week I've some command clashes problem and looking at the logs I couldn't identify why did that happened. The last time that this had happened the app was running for more than 24h, communicating with the remote control, without any communication issue.
Two of it's commands have some similar characters, the first one that have to be done, to establish the connection.
OK_CONN
And an sniffer command which keeps the pilot awake listening for some sensor data:
N
Looking at the logs I can see the answer for command N, after applying the command OK_CONN.
Is it possible for a Bluetooth command to lost part of it's data, during an established communication or am I doing something wrong when writing to a characteristic? Should I change the command names to avoid this kind of clash?
I'm using android 9, at a Sony XPeria XZ phone.
Edit to clarify #Emil comment
07:02:12.880 [BleThread] writing <OK+CONN> to characteristic
07:02:12.368 [Binder:19249_F] [onCharacteristicChanged():274]:
n command confirme
Looking at the logs I see that the last written command as an ok_conn but it has written only the N, this is been show as the last line, it has confirmed to receive the n command alone, instead of receiving the full data of ok_conn.
By name clashes I mean that maybe the last N of the ok_conn command is been accepted as the command.
I just realized what's going on, you can post that as an answer #Emil, my problem was at the logic that sends the first command, sometimes I send this command and the micro controller is not started yet, that's probably the reason of it getting only part of the command.
Not sure what you mean by name clashes, but Android will always write what you told it to write, without packet loss, as long as you follow the rules to never have more than one outstanding operation (always wait for callback before you send the next operation) and that your data must fit within the maximum length for the corresponding operation.
All,
I am attempting to communicate, over an SPP profile, with an RN4678 Bluetooth chip connected to a microcontroller.
I never have a problem with the Android app. I can always pair (if not paired), connect, send messages to the chip, and disconnect. An example session is below:
%CONNECT,AB9876543210%
%RFCOMM_OPEN%
%TEST% <-- Message sent using the keyboard ("Byte Stream Mode" option)
%RFCOMM_CLOSE%
%DISCONN%
With the iOS app, I can always pair (if not paired), connect, and disconnect. However, if I cannot send a message to the chip. An example session is below:
%LCONNECT,499B107AB1B5,1%
%LSECURED%
<-- Here I try to send a message, but it is never received
%DISCONN%
The funny thing is that if I first connect/disconnect using the Android, and then I connect using the iPhone/iPad, reception is successful !!!!
%LCONNECT,499B107AB1B5,1%
%LSECURED%
%TEST% <-- Yeah !!! Microcontroller receives the message
%DISCONN%
As far as I know, that path for the processing is the same ... In other words:
if(msg equals "RFCOMM_OPEN" or msg equals "LSECURED")
go to state that monitors incoming messages
I, therefore, kindly ask the following:
1 - Have you encountered anything similar? Do you have any hints? What could the Android App possibly do that the iPhone app is not doing? What am I overlooking or not understanding?
2 - Are you aware of an app that works for both iOS and Android? What I mean, designed by the SAME guy/company?
If you need more info, please ask. I simply did not want to be too 'verbose'.
Thank you for your assistance.
Sincerely,
Vincenzo
All,
At my job we have been playing with two RN modules: the RN4677 (we started with this module) and the RN4678.
The module allows the user to enter (and exit) a command mode. The RN4677 allows bidirectional communication with a manager while still in command mode. The RN4678 does NOT allow bidirectional communication with a manager while still in command mode.
All I needed to do was exit command mode (by issuing the command '---\r'). Now both modules work with Windows/Android/iOS ...
To summarize:
command "$$$\r" to enter command mode
various commands, requests for settings, ...
command "---\r" to exit command mode (a must for RN4678)
Everything will now work fine for both modules
I must say ... that was painful to troubleshoot ...
Sincerely,
Vincenzo
I use the processCommandApdu() method in a subclass of HostApduService to react on NFC commands. This method gets called on the Android main thread. These commands should be processed and sent over the NFC channel sequentially. Therefore, I want to process them synchronously.
Is there any good way to enforce sequential order without blocking inside of the processCommandApdu() method?
There is no need for you to synchronize command processing. Sequencing is inherent to the ISO/IEC 14443 protocol: A command exchange always consists of a command sent by the reader to the card (HCE device) and a response sent by the card (HCE) device to the reader. A reader won't issue a new command before the response to the previous command was received. If a command times out before a response is received by the reader, the reader will interpret this as if the connection to the card was lost.
Therefore, unless the reader resets/drops the connection, you won't receive a new command before you sent a response to the previous command (either through returning no-null from processCommandApdu()) or by calling sendResponseApdu()).
I'm developing an Android App which i want to communicate with a device connected via USB. This device is delivering data all the time. These data are visible with a programm on the android linux shell.
My goal is to see those data in my App and after that deliver them via a Service to other Apps.
So my question is: Can i "open" a connection from my Android App to the USB-Port so im continuesly receiveing the data in my app, which are sent by the usb-device? And if yes, how would the code look like?
*Edit
Thank you for your answers, the app itself doesn't run on the commandline any more. So its no executable anymore but a shared library getting load by my android app.
It did before, but i want to be able to initiate the connection using NDK methods in my App to be able to see the data in my App itself. So I've tried to see if a connection is allready open.
I've added some functions to my code, so i can see if the usb-connection is open and i have the permission to that usb device.
UsbManager.hasPermission(device)
returns true, because I'm using an itent filter.
UsbManager.openDevice(device)
returns an UsbDeviceConnection, so i seem to have the access to use that device.
What im not capable of so far is receiving either iniciating the bus connection to by usb-device and of course either getting data input of that device.
Since my native code allready has a while(true)-method which is only using callbacks to send data to my app when actually data getting sent trough my usb-device i want to keep the work done in my c-code.
The only job my app should do is open the bus-connection once and after that be ready for callback from the c-code.
Is that possible?
If you have the app that runs on the command line, you can actually run a command line from within your app. Take a look at the Process class and the ProcessBuilder docs for full details. The example given is below
To run /system/bin/ping to ping android.com:
Process process = new ProcessBuilder()
.command("/system/bin/ping", "android.com")
.redirectErrorStream(true)
.start();
try {
InputStream in = process.getInputStream();
OutputStream out = process.getOutputStream();
readStream(in);
finally {
process.destroy();
}
}
For some work I'm doing, I want to have an emulated GSM modem which will communicate with an Android-x86 virtual machine over a Unix socket. The VM should see the emulator as a real modem and use it to send SMS (as the first pass of functionality).
So far, I've put something together which handles some AT commands and just replies "OK" to all the rest. For some commands, like "AT+CRSM", I just have a table of responses gathered from running the official Android emulator and looking at the radio log. For others, I maintain some state and construct answers; those commands include:
CFUN?
CPIN?
CGREG?
CGREG?
COPS?
CGREG=
CREG=
CPIN=
COPS=
CRSM=
CSMS=
CGSN
CIMI
CSQ
Android will boot, and send commands to my emulated modem, which answers, however it doesn't seem to be fully functional. Android doesn't detect any radio signal strength, for instance, just showing an "x" in the signal bar.
Does anyone know of a similar project, or just what AT commands are absolutely necessary to get some basic functionality?
Well, I'll answer another of my own questions, it's easier that way.
I ended up implementing an emulator which maintains a little bit of state, such as whether or not unsolicited CREG and CGREG messages are enabled, the network registration status & network name format (for the COPS command), and a message reference counter for SMS.
It supports the following commands:
CFUN?
CPIN?
CGREG?
CREG?
COPS?
CGREG=
CREG=
CPIN=
COPS=
CRSM=
CSMS=
CMGS=
CGSN
CIMI
CSQ
All other messages just get an "OK" response.
With the stock AOSP Android source running in an emulator with the "-radio unix:/tmp/phone" switch, I can send SMS messages and decode the binary PDUs into real messages. I will continue to add functionality so SMS messages can be injected back to Android, and hopefully open-source the code at some point.