We Keep Coding

Android emulate NFC with Smartphone as reader

I'm looking for a way to use my phone instead of a nfc card. To do that I would create an Android App.
I live in Switzerland and the national rail company uses a nfc card called "Swisspass" to load annual tickets, ... on it for conductors to read it and look if the ticket is valid. A year ago they issued a new function called "Swisspass Mobile" where in your app you can display a QR code for the conductors to scan. You can also add your pass to Google Pay as a loyalty program card. If you do so it shows you a url which looks like that:
HTTP://1SP.CH?S=SXXXXXXXXXXX
Where the SXXXXXXXXXXX is your member id. The problem with the QR code is that it takes way longer for the conductor to check and it is in general difficult to do so, as the train is constantly moving. If you take this url and generate a QR code form it in any other app it works as well.
So my thought was to use my phone to send this URL to the smartphone the conductor uses to make their and my life easier. I had a look at this
https://developer.android.com/guide/topics/connectivity/nfc/hce
but I can't really figure out what AID I would have to use or if I even need to use HCE in that case as it's not a NFC tag reader but a smartphone. Do you know any more information? Could I use peer to peer or just send the url by nfc to the conductors smartphone? How would I do that?
Thanks a lot in advance

Can't read Google Pay Pass event card through another phone's NFC reader

I need to make an app that is able to read the Google Pay Pass event ticket through NFC. But I can't find any way how to deal with it. I saw some top apps in Google Play, as PassWallet and Passes, which works with such event tickets.
But they all could add a new ticket through scanning barcode only, not through NFC touch. I tried to open a ticket in Google Pay app and read it through another phone's NFC reader but didn't receive any information about the ticket, I always receive my default credit card info even when I open needed card.
So my question is that is it possible to read Google Pay Pass event ticket through another phone's NFC, as in the picture below?
If yes, could you share with me some example codes on how to do it?

Yes it is possible.
For a Google Pay issued pass the pass must be saved to google pay on the mobile device and that passes class must be set to enable smart tap and the pass itself must have the smartTapRedemptionValue field set as below:
{
...
"smartTapRedemptionValue": "Value to Transmit",
...
}
The device acting as the terminal (reads the pass) must implement the Smart Tap Protocol and present the collector id, and signed payload to the mobile device to authenticate the terminal and send passes that it can redeem.
The passes class also has the field redemptionIssuers can specify which terminal's collector id can redeem it.
In order to implement Smart Tap Protocol you can request access to the NDA protected docs via a form and that has the details on how to configure a device acting as a terminal to read passes.
There are also already certified supported terminal providers available.

Having problems getting Weight Data with Android from a BLE Scale

I'm currently developing an android app for a weight scale I received that transmits data through bluetooth low energy.
I was looking at documentation and if I got the information correctly, there are specific UUIDs for data. I received a BLE scale with a Chinese protocol document found here: http://www.anj.fyi/protocol.pdf
I found and was able to get a functioning scanner working that lists the device name and the UUIDs it broadcasts.
Lets say I want just the weight data to show up in the UI, nothing else and nothing more.
I don't know what UUID they used for the weight data, and there are a lot of UUIDs. Probably 20+. I checked a UUID compilation and the usual weight data UUID does not show up.
How do I get the data from those UUIDs?
I'm thinking it might be the ones that are notifications, indications or read properties.
Looking at the UUID for example, f000ffc2.
How would I get data from that characteristic? Would anyone have an example code to grab the data from those UUIDs, or tutorials because I'm terribly lost right now.
I really appreciate it.

There are no weight information on the document you list http://www.anj.fyi/protocol.pdf, it is only shows the BLE module hardware interface spec, i.e. it does not specify the detailed service and characteristic.(I an a native Chinese speaker).
Regarding to the UUID you want to know which is the one to represent the weight, yes you are right it should be the read/notification feature without write permission. Can you use the apps e.g. lightblue on iOS to receive the notification(meanwhile change the value on your device) to test it? this will help you to understand which characteristic is the one you want.

How should I manage Bluetooth connections in Android?

Q. What are your best practices in managing bluetooth connectivity?
I've read the android bluetooth guide & many bluetooth connectivity tutorials. Not helpful with encapsulation-design nor best practices.
When should I open/close the connection?
Is the "connection" with a single bluetooth device called a "socket" connection?
Can a single connection send data while listening? (...or between listening states).
I've never coded connectivity with external devices before. It took two weeks for me to wrap my head around the code that scans for near-by bluetooth devices and throw them into a ListView. Listeners, Broadcasts, and Adapters!
My project will be printing 1-40 receipts every 15 minutes on a bluetooth receipt printer. At the moment, security is not an issue. On the same connection, it will also be receiving data (sending & receiving simultaneously does not appear to be necessary but would be useful). I'm not yet sure how the devices are configured on this single dongle device but I would guess the devices are connected via USB controller to the dongle.
So far, I have 1 object to manage a single I/O connection. Staticly I open an activity to select a connection (to later save the label, mac, and pin in the database). Based on tutorials, I have "open", "listen", "send", and "close" methods. What confuses me is "how" to use these functions. Can I leave a connection open all day (10hrs) and use it every 3mins? Should I open/close the connection when sending or requesting data? Where would I detect the need to reconnect?

sorry for the short answer, but from my practice with the Bluetooth API, I have found that this video describe the things very good (totally personal opinion...)
Video 1
In addition this is useful when you do NOT have any previous experience
Tutorial
And as last check out this question in stackoverflow it has a bunch of good references and examples!!
Again sorry for the shortage, but I believe that if you check these out at least most of your questions and concerns will become answered!
:)
EDIT
So, let me be a bit more descriptive and share some of my experience.
I have written an App that communicates with BLE device that has 3 functions
double sided event driven button (push the button on phone -> event is fired to the device; push the button on the BLE device -> event is fired to the phone)
send request from phone -> BLE device answers with current battery percentage
continuously reading strength signal (as aprox. distance) between the phone and the BLE device
So far so good, now the things is that the basic approach is:
Search for BLE devices (bluetooth search or "discovery" of nearby bluetooth devices)
Here you will need android permissions!
Choose the device you want to connect to
To differ the devices (maybe there are a lot around you :) ) you can use BLE device's name or UUID or ... best - use the name ;)
After both devices connect to each other you can then start the Gatt communication. The approach with state machine is a little too much overkill for me. But anyway the communication is done through bytes (in my case...)
In one of the videos/resources there was something specific and VERY HELPFUL at least for me! To be honest I don't remember it exactly, but the idea was that before any communication it's RECOMMENDED to read/get all the options from the BLE device or something similar...
Maybe it was something like discoverOptions() or something like that
Great thing will be to know your device "communication codes" or at least I call them that way.
Check this link for example: Link
** Now you can see there are tables with the USEFUL INFO! E.g. if you want to read the battery level you navigate to this page and find that in order to read the battery, the service name is UUID XXXXX and you need to send 0x01 to the BLE device and it will "answer" to your call with some data which is again in bytes.
I really hope that this is somehow helpful!
PLEASE NOTE
This is strictly coming from my experience and there could be some mismatches or wrong terms, but that's how I personally see the things and because my project was long ago, I don't remember most of the things exactly.

IMPORTANT:
This is only a summery of STUCI's provided links above. He has since updated his answer and I have not updated/edited this summery. Topics in my summery are not explanatory but provided for reference and help in generating specific questions.
Original Post...
Thank you Stuci! Some of that was helpful:- some not. I thought it best to collect my thoughts and see what has been explained and if anything hasn't.
(I can't post this much in a comment tho, sorry)
PLEASE CALL ME ON ANYTHING THAT IS INCORRECT.
Video of Bluetooth LE
(Covers a bunch of random things)
While I "dont-like" videos of code:- I watched it because it was recommended ... and I am glad I did. While not very helpful it did introduce some concepts I was unaware of. Since I am targeting old android devices (v8+) the LE features are inconsequential.
Pushing Data: [Depending on the source feature-set], one does not need to continually pull data (ex. with a temperature sensor) but some devices can "push" it to the device on change. Seems to use the 'advertisement" design concept.
UUIDs define Services and/or Characteristics of the connected device.
Possibility to write configuration on (to) connected devices.
Characteristics which seem to be simply "settings" that can be assigned over bluetooth. Not sure if this (~19mins) applies to non-gatt connectoins but seems similar to the state-machine that controls
Advertisements which seem to be the "metadata" regarding the devices current state or config (~24mins). Again, not sure if this even applies to non LE Bluetooth.
Leaving Connections Open
Bluetooth connections can indeed remain open; starting at the point which the "startActivityForResult(...) method is successfully called.
Two basic things affect whether or not one would want to maintain an open connection:
Understand the power consumption.
Having the adapter active simply consumes additional power. If one can keep the adapter shut-off while it is not "absolutely-needed" will mearly save battery power.
Accidental disconnects are managed.
Other than leaving the connection continually connected, one could disconnect & reconnect regularly at specified intervals to ensure a connection is up.
In the thread(s) used for I/O, one could check for a disconnect and reconnect (possibly starting a new thread).
I/O Streams pr Connection
A single connection can indeed "have" simultaneous Input & Output streams. I
Since it was suggested, I re-read Android's Bluetooth Guide and under "managing a connection" (talking about a single socket) I noticed this...
Get the InputStream and OutputStream that handle transmissions through the socket, via getInputStream() and getOutputStream(), respectively.
Read and write data to the streams with read(byte[]) and write(byte[]).
...but continues with noting that read & write block each other. Something I still need to look further into. It seems like you cant I/O simultaneously on the same socket???
Max Connections
I also looked into the max connection issue Stuci added and found no documentation on the Android-side. It might exist, I cant find it. However, most people seem to agree that there is a limitation (that could be as low as 4) imposed by whatever hardware you are coding for.
Some notable links:
- How many devices we can pair via Bluetooth of BLE to Android?
- How many maximum device can we pair via Bluetooth to android device at a time?
- https://groups.google.com/forum/#!topic/android-developers/adeBD275u30

Is telephony manager values reliable and changeable (cdma)?

I want to know if I can rely on the telephony values like country, MCC, etc on Android for my app. Can I change them on the run using setprop? I tried changing using setprop it didn't seem to work. From my understanding telephony manager is a class/interface which represents Hardware configuration of GSM or CDMA. In case of GSM this could be sim and in case of CDMA it cud be a hardware. My questions are:
Who update these values in both the cases for the first time?
Are these values are saved by OS as read only?
What if a user travels to different country or zone will some of the values like country code and MCC values updated automatically?
Can I reset these values?
I have no intention of changing any of these values but want to understand its working! I would appreciate if someone can help me on this.

According to android documentation
Provides access to information about the telephony services on the
device. Applications can use the methods in this class to determine
telephony services and states, as well as to access some types of
subscriber information. Applications can also register a listener to
receive notification of telephony state changes.
TelephonyManager is used for reading phone information. Regarding your question about MCC & MNC codes: yes, they will change when phone will be in other country. You can subscribe to receive those events and determine that user now in different country.

#Bo
The way CDMA works is different from GSM. CDMA has always got one home base and many visitor base location. and you can always get to know about visitor Operator using TelephonyManager methods which is considered as unreliable for CDMA.

I decided to add it as answer as well...
I found a way to tackle this problem on CDMA phone.. if it is a CDMA phone , then the phone always has an ICC hardware comparable to SIM cards in GSM. All you gotta do is use the system properties associated with the hard ware . Programmatically you can use Java reflection to get this information . This is not changeable even system is rooted unlike GSM device. Class c=Class.forName("android.os.SystemProperties"); Method get = c.getMethod("get", String.class); String homeOperator = ((String) get.invoke(c, "ro.cdma.home.operator.numeric"));