I used System.getProperty("wireless.messaging.sms.smsc") but it is showing some other number. How to get mobile number, operator of the SIM which is used and to check data connectivity.
Ok, short answer: You can't get the phone number.
see this answer
The properties you have to read to get thinks like IMSI, MNC, MCC are completely vendor/model specific so unless you can't give these refer to this post
Concerning connectivity, I am not sure whether you mean availability of internet or wireless connectivity or something else. But in most cases the answer would be: You will have to check if the device vendor offers an SDK for that.
Related
I have inherited an application that connects to a ble device.
The app searches through devices that are scanned, and connects to the one that has a name that matches the expected name.
Pretty simple question...is this the standard way of connecting to a type of device?
Should I use something more specific like inspecting the services for the expected service ids?
The general approach is to filter the scan results using service uuid present in the advertising data. Name is not a good filter approach since it's supposed to be user friendly, and on many devices a user can put their own name, and potentially the same one as you are using.
Can I have any 16-bit/32-bit UUID in advertisement packet for like filtering purpose?
Is it mandatory to have the list of service UUID listed in advertisement packet to be available in service discovery after connection?
Can I have standard GATT services to have unrelated service data in advertisement packet?
Can manufacturing data be made with custom manufacturer ID and data?
Where can i find the legality on these questions on both commercial and non-commercial purposes?
I want to make a BLE server in both android/iOS and also on a development board and I can't find relevant sources stating the legality on these standards.
The relevant source to look at is the Bluetooth Core Specification Supplement (CSS) which you can find here: https://www.bluetooth.com/specifications/bluetooth-core-specification/.
As you can see, it is very loosely specified. The Core Specification also does not say so much about the different AD types.
The spec says in the description "The Service UUID data type is used to include a list of Service or Service Class UUIDs." The spec then describes the different formats 16/32/128-bit UUIDs, incomplete or complete list. Other than that the spec doesn't say where this list comes from or what it represents. It however uses the formulation "If a device has no Service UUIDs of a certain size, ..." at one place. The spec though says that "16-bit and 32-bit UUIDs shall only be used if they are assigned by the Bluetooth SIG" so you can't pick any unassigned 16- or 32-bit UUID. So no you can not just pick any random 16- or 32-bit UUID, it must be an assigned one.
As in 1. the spec doesn't say which list should be advertised. But it is common knowledge that it should represent the list of GATT services that are present in the device's GATT database.
The spec for "Service Data" is very short. The description consists of one sentence: "The Service Data data type consists of a service UUID with the data associated with that service". For the data format it then says the data consists of the UUID followed by "additional service data". It is here, again common knowledge (I guess?) that the associated data must be defined by the specification of the particular service. for example, the Cycling Power Service defines the data as follows: "Cycling Power Service UUID followed by the Cycling Power Measurement characteristic value". So usually the associated service data consists of the characteristic value of a characteristic that has the Broadcast property enabled.
If the CSS is strictly followed (word by word), you could argue that it's possible to use a different list of service UUIDs than the ones in your GATT database. You could also argue that the manufacturer could put in its own "associated data" with a service in a Service Data record. I would say these are possible interpretations, but it's not what the one who wrote the spec intended.
The spec for "Manufacturer Specific Data" has the following description: "The Manufacturer Specific data type is used for manufacturer specific data. The first two data octets shall contain a company identifier from Assigned Numbers. The interpretation of any other octets within the data shall be defined by the manufacturer specified by the company identifier." This means you cannot "steal" another company's identifier and use a data format defined by you.
Note that Bluetooth is way older than the smartphone era. In the beginning, everyone that implemented Bluetooth was for the purpose of selling a product that uses Bluetooth technology (earphones, speakers, phones). Still at this day, when making a Bluetooth "product", you need to be a Bluetooth SIG member (which is free but only companies can be Bluetooth SIG members) and when you use any of the Bluetooth trademarks with the product you need to get it qualified and listed at Bluetooth SIG. You can read at https://www.bluetooth.com/develop-with-bluetooth/qualification-listing/ what actions and enforcements are taken if you fail to qualify a product. To qualify a product, you must follow the spec. There is a full test suite for qualification that you must pass. I'm pretty sure though it wouldn't catch if you use the wrong service list or "steal" a manufacturer's company id in manufacturer data. Developing software apps that run on already Bluetooth qualified smartphones is something that Bluetooth SIG hasn't thought of in my opinion. They have an option of qualifying as a "GATT-based Profile Client (app)" that costs $100 (https://www.bluetooth.com/develop-with-bluetooth/qualification-listing/qualification-listing-fees/), but that apparently isn't for you since you implement the Server profile. I have so far not heard of anyone that has done this app qualification. So to me it's a bit unclear how smartphone apps should be treated.
In the end the idea is that everyone should follow the spec to ensure proper interoperability between different products.
For your particular case, if you just want to minimizie the Advertisement data, just request a Company ID from Bluetooth SIG (it's free) and use Manufacturer Specific Data.
I'm working on a project to track delivery trucks leaving and returning to the office.
While I know RFID would work, we're also looking at BlueTooth with mobile apps. Ideally, once a driver installs the app, we register a unique ID for the device, and a BT reader identifies when phones/deliveries leave and enter range without any user interaction.
From the Android 6.0 release notes, it looks like the MAC address is hidden from apps and BT broadcasting. https://developer.android.com/about/versions/marshmallow/android-6.0-changes#behavior-hardware-id
User management of app installs and enabling BT aside, is this feasible?
Can someone point me in the right direction to confirm what identifiers are available?
When I understand you correctly you actually do not want to track where a phone is but want to know if a person/truck/phone passes a kind of checkpoint or gate?
For newer smart phones you cannot rely on the visible MAC. Bluetooth classic is usually not visible and the BLE MAC is randomized as long as the device is not paired and bonded.
Indeed as PaulW11 stated, the simple way would be to implement an app which does BLE advertising with short advertising interval. Inside this advertisment you can put some custom data. This will be visible to everyone. This ID can be some random number, a number assigned by you or whatever.
At the gate you would implement a BLE scanner grabbing all advertisments near to it.
This should be easy to implement.
I would also like to mention the drawbacks here: If someone passes the gate you may miss him. BLE with Android is always tricky and you might have the situation that the bluetooth subsystem on a phone may have stopped working or so.
One the other hand if someone comes accidently near to your gate, you will think he left or returned. Near can be something around 50 m or so with good conditions or only 10 in other cases.
And even worse: If someone stays 'nearly' in the range of the gate you will see im sporadically. This may confuse your come and go logic if he is visible every 3 minutes or so...
I've patched android with SEEK for Galaxy S3 and after some struggle I'm now able to send APDUs to SIM card and get proper responses.
I want to place my own applet inside SIM but since there is no way we can get the access to do so, I start to wonder if there is anyway we can issue a java card to work like a SIM card. All I need is a java card that the phone can't distinguish from a SIM, no network coverage is needed and I know it is almost impossible to create a SIM that works OK with operator and gives network coverage.
The reason for all this is I need to send APDUs and work with my applet, but if I insert a java card instead of a SIM card in GS3, it gives me no access at all.
So my question is this:
Is it possible to issue a java card so that it looks like a SIM by the phone (and not the operator)?
or Is it possible to change android so that it gives needed access when there is a java card in it, i.e. RIL works as usual?
EDIT
Okay, I think I'll try to issue a Java Card with following properties:
First, it will have an auto selected applet (default applet) that from now on will be call fake-UICC.
Second, in fake-UICC we'll emulate the file system of UICC (according to http://www.in2eps.com/fo-uicc/tk-fo-uicc-mf.html).
Third, since different class is used for SIM APDUs (0xA0) so All APDUs sent from RIL will be directed to fake-UICC by JCRE, since class+instruction is not recognized by normal Java Card. e.g. 0xA0A4 is select for SIM but 0x00A4 is select command for Java Card.
In last step, we will try to send exact same responses a real SIM would send to each APDU.
Maybe it won't work but I think it's worth a try.
SIM Card (UICC) accessed through SEEK is not the only secure element you can use in your cellphone.
On the market there are other Java Card solutions: mostly based on microSD slot (provided e. g. by GoTrust or Feitian Technologies), which you should be able to access through SEEK.
Some cellphones (Galaxy S3 is not this case, unfortunately) are equipped with a special secure element slot, which you can insert common smart card (mostly by Oberthur) into and access through SEEK (see http://www.nfcworld.com/technology/embedded-secure-element-ese/ for some devices with this feature).
There is an interesting article about SE options: http://nelenkov.blogspot.cz/2012/08/accessing-embedded-secure-element-in.html
If you know some other vendors offering microSD Java Card products, please write them down in comments and I will add them to my post. This answer is not supposed to be any advertisement for the companies mentioned above.
Well, Actually I'm not sure if this solution works or not, and as dear #Vojta mentioned in the comments under his answer I would like to discourage people from the following attempts. It will be difficult, time-consuming and probably with no useful results. He knows a lot more than me in this field.
Anyway, as you wanted I posted my suggestion:
Each file in the system file of the SIM/USIM card is linked to a hexadecimal number as its addresses (AID). These AIDs are defined in GSM and ETSI standards (GSM 11.11 for example). You can write some Javacard applets to simulate that system file.
As SIM/USIM card's AIDs are shorten than JavaCard AIDs, you might need to choose a Java Card that support partial AID selection and use this capability to refer incoming command to its associated applet.
I think you can simulate all the system file inside a single applet also and then make that applet default selected applet.
If you had any success with this solution, please inform us. :)
I am Developing a Java ME Application. Here I am using WiFi Connection. Now My Question is how to get a particular WiFi Connections name using Java ME Code ?
My Requirement is for Nokia E5 Device only.
After doing much research work I found that this is not possible in Java ME Technology to fetch the WiFi Connection's Name.
However Similar Library would be com.nokia.multisim.networkid which returns Network ID and Network Short Name.
I Dont Think so it is 100% possible in J2ME and even though if it has worked and there is no guarantee that it will work on all J2ME devices which has Wifi connectivity.
most appropriate answer i have found , please go through it once.
" Much as I hate to put you through all that grief and then not have a simple answer, I don't have a simple answer.
The reason for that is because Java's networking model is based on TCP/IP, and the TCP/IP architecture is based on the idea that applications will neither know nor care about the hardware details of networking. A typical mobile device may contain several different network interfaces (WiFi, Bluetooth, Infrared, USB cable, and so forth), but when an app wants to contact another network node, the app doesn't know which of these interfaces is actually being used. And in fact, if the OS wants to do so, it can use more than one (in parallel) and/or switch interfaces in and out, based on routing criteria such as best measured data rates. Rather like how cell phones route phone calls.
So basic Java/JME won't know anything about WiFi.
However, there is an extension, specified as JSR 309 (http://jsp.org) that looks like it may help. It supports learning about and controlling the network interfaces themselves. The problem is that not all devices will implement this extension, so it will depend on what device(s) you are supporting. "