We Keep Coding

receive Bytes from pc in android device via usb

I want to know how to receive like 100 bytes of data in my android device, I send from my program:
public void sendVoucherInformationToPhone(String data) {
this.targetDevice.openPort();
this.targetDevice.writeBytes(data.getBytes(), data.getBytes().length);
this.targetDevice.closePort();
}
//the library used in the program is JSerialComm
Screenshot of the program:
I can detect the device itself, But as I said, I have no Idea how to receive the bytes on the other side, so is there any help you can offer me?
(I did read the doc in the official android website but didn't get it, so if any example code or even pseudocode would be so helpful)
thank you

ELM327 returns `?` when trying to use it with ODB Java API

I'm trying to use ODB Java API (this library) to get the data from ELM327 via Bluetooth from my car, but in returns ? on every request, and library raises MisunderstoodException
Here is my code:
socket = device.createInsecureRfcommSocketToServiceRecord(uuid);
socket.connect();
final CustomRPMCommand engineRpmCommand = new CustomRPMCommand();
final SpeedObdCommand speedObdCommand = new SpeedObdCommand();
while (!Thread.currentThread().isInterrupted()) {
engineRpmCommand.run(socket.getInputStream(), socket.getOutputStream());
speedObdCommand.run(socket.getInputStream(), socket.getOutputStream());
runOnUiThread(new Runnable() {
#Override
public void run() {
speedometerGauge.setSpeed(engineRpmCommand.getRPM(), true);
rpmGauge.setSpeed(speedObdCommand.getMetricSpeed(), true);
}
});
}
What's wrong?

I also used the same library for the first steps into trying out OBD, so I can say at least at the time I used it, it worked fine.
From my experience however, getting ? back can sometimes happen with cheap Bluetooth devices (maybe even with expensive ones? never had one). I guess this happens, if some bits are lost during the transmission, because then command will be misunderstood.
What I did to circumvent this problem is setting up a process where I sent all AT commands up to 10 times until I get the desired response of OK (except for ATZ, which will respond with ELM327). As for value requests like RPM etc. I usually just throw away the erroneous values.
That's the short answer, but since such problems with the devices can annoy a lot, I will guide you into debugging the whole process...
Setting up a terminal on windows
First of all to test the functionality of the ELM device, you can send commands to the serial interface directly. On windows, this is possible using for example TeraTerm and then setting up new Bluetooth connection on your windows as a COM device (search for Bluetooth in start -> search box and then choose Change Bluetooth settings or similar). From there, go to COM connections and then add a new one Outgoing for the Bluetooth OBDII device. Wait a bit for windows to calculate the new COM port number, you will need it.
If you cannot find OBDII in the dropdown box, you have to bond your PC with your Bluetooth device first. This can be done via devices and printers, there you should see the OBDII device, so you only have to connect it (PIN usually is 1234).
If you're on Linux, it might be somewhat easier, but I haven't done it :)
Sending some commands via terminal
Once you have your Bluetooth connection and TeraTerm installed, you can start TeraTerm and connect to the adapter. Choose Serial and then the port you just set up. Ensure, that no other device is connected to the OBD adapter (also not your phone). Only one device can be connected at a time.
If connection was successful, you should be able to type letters. Usually, in default settings you should be able to see the letters you type (Echo mode on), but since this is not certain, just type ATZ and hit <Enter>. The ELM should respond with "ELM327" in the same line now (which for me usually results in odd display if echo mode was on, but you should get any response).
From terminal I usually send these commands in order:
ATZ
E1
L1
010c
This will trigger:
Reset of the OBD device
Make sure that echo is on, so I see what I am typing
Make sure Line feed is on, so we get responses in the next line
Request RPM from the vehicle
Between each command I'll check what is the reply of the device. For all AT commands (1., 2. and 3.) it must be OK. If I get back ?, which can happen, I will repeat the command another time. You will see that in such a case the device indeed did not follow the instructions, e.g. did not set line feed on if it was off. So we really have to send it again.
In programming mode on the other hand, we will set e0 and l0 (echo mode off and line feed off), because we do not want to get sent back what we already sent out.

Cisco JTAPI to CUCM

I have been tasked with writing an application that lets users place calls to Cisco Unified Callmanager 8.6. The contact list will not be provided by the UCM. It will be provided elsewhere.
I find both the documentation and examples provided by Cisco to be lacking and undesirable. I also find the lack of working examples from third parties to be lacking.
My hope is that someone else has done something similar to this before me.
The application gets the numbers to call from a database, it then lets the user click on the contact he or she wants to call. The number of the destination should then be sent to the phone. Basically, in stead of having to dial a number, the application sends the destination to the phone or UCM and the user takes over at this point.
Looking at Cisco's makecall.java, and using it, it seems to be simple to actually place a call using this API.
I have started out by using the example found at http://blog.nominet.org.uk/tech/2008/01/25/experiments-with-jtapi-part-1-making-a-call/ but I believe this piece of code to be insufficient to place a call. I may however be wrong.
Could anyone point me in the right direction here, as I believe my specifications are simple and should be easy to implement. If more information is needed, I will be happy to provide it.

This is months ago, but it still might help you somewhat. I was able to create a test scenario:
protected CiscoJtapiPeer peer;
protected CiscoProvider provider;
// ...
peer = (CiscoJtapiPeer) JtapiPeerFactory.getJtapiPeer(null);
provider = (CiscoProvider) peer.getProvider(cucmURL);
/* cucmURL has the format:
"192.168.0.20;login=myuser;passwd=mypasswd"
whereas the username is an Application User in Cisco Unified Communications
Manager. On my system, it has the following permissions. I don't know whether all
of them are required:
Standard AXL Users
Standard Audit Users
Standard CCM End Users
Standard CCM Phone Administration
Standard CCM Phone and Users Administration
Standard CCM Read Only
Standard CCM Super Users
Standard CTI Allow Call Monitoring
Standard CTI Allow Call Park Monitoring
Standard CTI Allow Control of All Devices
Standard CTI Allow Control of Phone supporting Connected Xfer and...
Standard CTI Enabled
Standard CTI Secure Connection
Standard RealtimeAndTraceCollection
Standard TabSyncUser
You then add an observer to the provider in order to know when the provider
object is read for further interaction. You'll receive a "ProvInServiceEv" Event in the event list.
*/
provider.addObserver(providerObserver);
/* Wait until the event has come up */
// Create a sample call:
CiscoTerminal term = provider.createTerminal("your_sep_id_here");
Call call = provider.createCall();
call.connect(term, term.getAddresses()[0], "your_phone_number_to_call");
term is used as "source" from which the call is started. term.getAddresses()[0] just gets the first phone number associated with the "source" phone. "your_phone_number_to_call" is then called.
Another info: It does not work the other way round: You cannot call provider.getAddress("phonenumber") first, because somehow the phone numbers aren't loaded by the provider class before any terminal is connected to it.
This was tested on a CUCM 8.6.2 and Java 7.

I used this code in my project, works correctly:
final Condition inService = new Condition();
provider.addObserver(new ProviderObserver() {
public void providerChangedEvent(ProvEv[] eventList) {
if (eventList == null) {
return;
}
for (int i = 0; i < eventList.length; ++i) {
if (eventList[i] instanceof ProvInServiceEv) {
inService.set();
}
}
}
});
inService.waitTrue();
Address srcAddr = provider.getAddress(src);
co = new CallObserver() {
public void callChangedEvent(CallEv[] eventList) {
}
};
srcAddr.addCallObserver(co);
call = provider.createCall();
call.connect(srcAddr.getTerminals()[0], srcAddr, dst);
src - phone which you are calling from
dest - phone which you are calling to

android device id confusion

If I dial
*
#
*
#
8
2
5
5
#
*
#
*
, I get my android device id which starts with android-35c2acdd...
source
If I use Settings.Secure.getString(getContentResolver(), Settings.Secure.ANDROID_ID) the result starts with a96b4b27...
If I use ((TelephonyManager) Context.getSystemService(Context.TELEPHONY_SERVICE)).getDeviceId() the result starts with 3538330...
What is the difference between these ID-s? How can I get the result of the
*
#
*
#
8
2
5
5
#
*
#
*
dial?

IMEI
The IMEI is the 'MAC' for the telephony module - the unique ID that the telephone uses when it connects via GSM/GPRS/HSPDA/etc. The GSM network uses it to route calls and data from the phone over the GSM network right up to the gateway into the Internet (which is an IP network).
A telephony module is a chip or circuit board that handles the telephone network, either GSM or CMDA, and often has a slot for a removable SIM card. Some phones have more than one telephony module (active dual- or multi-SIM phones). Each telephony module has its own IMEI.
Manufacturers give each phone (strictly the telephony module) a unique IMEI during manufacturing. However the number can normally be rewritten if you have the right software. This is often done after a phone has been stolen to give the phone a new identity and bipass stolen phone blocking system.
The IMEI can be programmatically obtained using the TelephonyManager.getDeviceId() API.
CDMA phones have a ESN or MEID which are different lengths and formats, even though it is retrieved using the same API.
Android devices without telephony modules - for example many tablets and TV devices - do not have an IMEI. As Schlangi commented, some devices that do not have a telephony module fake the IMEI, so the presence of an IMEI does not (always) guarantee the device has a telephony module.
ANDROID_ID
The ANDROID_ID is another unique number on the phone - this is automatically generated by the OS as it boots for the first time (doing it this way makes it much easier for the manufacturers by removing a step from the production line).
The ANDROID_ID can (and does) change, for example:
Factory reset (including when reflashing the OS)
In software: eg https://play.google.com/store/apps/details?id=com.vcastroi.changeid
It is mainly used by developers (eg identifying and connecting to devices using adb)
ANDROID_ID can be used to identify an Android device given the caveats above, realistically meaning that it uniquely identifies the device over significant portions of the device lifetime, but cannot be relied on.
Also note that there was a bug in Froyo where many devices gave themselves the same ANDROID_ID. This is the bug
Other identifiers
There are a number of other things that can be used identify the device:
MAC address of the WiFi module: WifiManager.getConnectionInfo() -> WifiInfo.getMacAddress(). This can often be changed in software, but generally is constant over the device lifetime. Also it can only be read if the WiFi module is switched on.
MAC address of the BlueTooth module: BluetoothAdaptor.getAddress(). Like WiFi MAC, this can often be changed in software and may be off when you need it
The subscriber's telephone number. This may change if the user requests a new number from the telco, or if the user switches SIMs. It is obtained from TelephonyManager.getLine1Number(). This is only present for Android phone devices with a current SIM installed and a paid service with a telco.
The SIM contains its own identifying number (IMSI). This is obtained from the TelephonyManager.getSubscriberId() API. Obviously the SIM may not be present at any specific time, and it changes when the SIM is changed - and users can upgrade/replace their SIM while keeping the same number, so you can't say that this is one-to-one to a specific phone or user.
Related to the IMSI is the MSISDN. This functions as the identification of a subscription (your contract for a specific telephone number with your mobile provider) and therefore gives the device its telephone number. The MSISDN may be associated with several SIM cards, and therefore several phones. It comes with all the caveats for reading the SIM above. This may be retrieved with TelephonyManager.getSimSerialNumber(). Thanks Schlangi for the corrections and additions
Gingerbread and later has android.os.Build.SERIAL which many manufacturers set (but not all. Bugger).
Other notes
You need specific permissions to access each and every API, so if you try for all of them, your app's permissions in the Google Play store look fairly permissive.
I think this link explains all the other available options also https://android-developers.googleblog.com/2011/03/identifying-app-installations.html

Found on the web:
private static final Uri URI = Uri.parse("content://com.google.android.gsf.gservices");
private static final String ID_KEY = "android_id";
String getAndroidId(Context ctx) {
String[] params = { ID_KEY };
Cursor c = ctx.getContentResolver()
.query(URI, null, null, params, null);
if (!c.moveToFirst() || c.getColumnCount() < 2)
return null;
try {
return Long.toHexString(Long.parseLong(c.getString(1)));
} catch (NumberFormatException e) {
return null;
}
}
Add permission:
<uses-permission android:name="com.google.android.providers.gsf.permission.READ_GSERVICES"/>
However, I doubt that is a documented ID and I would be carefull because that might not work if GTalk gets updated.
Source: http://blog.codepainters.com/2012/01/17/how-to-obtain-gtalk-android-id/
Also worth having a look at: http://www.toxicbakery.com/android-development/getting-google-auth-sub-tokens-in-your-android-applications/

There are some approach to get unique identifier on android phone.
Android ID
It is a 64-bit hex string which is generated on the device's first boot.
Generally it won't changed unless is factory reset.
Secure.getString(getContentResolver(), Secure.ANDROID_ID);
The Android ID , considered unreliable because it can sometimes be null.
The documentation states that it "can change upon factory reset".
This string can also be altered on a rooted phone.
String m_szAndroidID = Secure.getString(getContentResolver(), Secure.ANDROID_ID);
Returns: 9774d56d682e549c . No special permissions required.
2. The WLAN MAC Address string, is another unique identifier that you can use as a device id.
Before you read it, you will need to make sure that your project has the android.permission.ACCESS_WIFI_STATE
permission or the WLAN MAC Address will come up as null.
WifiManager wm = (WifiManager)getSystemService(Context.WIFI_SERVICE);
String m_szWLANMAC = wm.getConnectionInfo().getMacAddress();
Returns: 00:11:22:33:44:55 (not a real address since this is a custom ROM , as you can see the MAC address can easily be faked).
WLAN doesn't have to be on, to read this value.
3. The BT MAC Address string, available on Android devices with Bluetooth, can be read if your project has the android.permission.BLUETOOTH permission.
BluetoothAdapter m_BluetoothAdapter = null; // Local Bluetooth adapter
m_BluetoothAdapter = BluetoothAdapter.getDefaultAdapter();
String m_szBTMAC = m_BluetoothAdapter.getAddress();
Returns: 43:25:78:50:93:38 . BT doesn't have to be on, to read it.
4. IMEI only for Android devices with Phone use:
TelephonyManager TelephonyMgr = (TelephonyManager)getSystemService(TELEPHONY_SERVICE);
String szImei = TelephonyMgr.getDeviceId(); // Requires READ_PHONE_STATE
This requires adding a permission in AndroidManifest.xml, and users will be notified upon installing
your software: android.permission.READ_PHONE_STATE. The IMEI is unique for your phone
and it looks like this: 359881030314356 (unless you have a pre-production device with an invalid IMEI like 0000000000000).
For more info refer this link.

IMEI
There is a mandatory requirement by the standardization bodies, that mobile devices for public networks may be uniquely identified by the IMEI number
It is the manufacturer's responsibility to set IMEI. In practice, developers sometimes see IMEIs like 000000... or 123456... Sometimes phones with identical IMEI go to production, which of course is a bug that should be fixed...
ANDROID_ID
A 64-bit number (as a hex string) that is randomly generated on the device's first boot and should remain constant for the lifetime of the device. (The value may change if a factory reset is performed on the device.)
It looks like Android does not trust the manufacturers and provides an alternative unique ID.
EDIT:
This is what I get (instead of IMEI) on and Android device that is not a phone:
$ adb shell dumpsys iphonesubinfo
Phone Subscriber Info:
Phone Type = GSM
Device ID = null

I think all the information provided above is well enough to understand the codes.
Yet I think you are still "not able to see the result of the ##8255## dial" (plz excuse if I went wrong somewhere in understanding this)
I assume the reason behind this is one of the latest bug fix against USSD code made in Android.
(you may read more about this and check if your device is on the list. its all over the web)
Finally, if you just want to get the android ID straightaway i suggest you to use this app-
https://play.google.com/store/apps/details?id=com.redphx.deviceid&hl=en

Bluetooth on Android - how to connect to the CORRECT bluetooth device?

I'm writing a program that speaks with an external accessory over rfcomm.
My problem is that I don't know what the correct way of identifying my device is.
the way I do it now is like this:
Set<BluetoothDevice> pairedDevices = mBluetoothAdapter
.getBondedDevices();
for (BluetoothDevice device : pairedDevices) {
if (device.getName().equals(MY_DEVICE_NAME)) {
this.myDevice = device;
break;
}
}
This method however relies on the name of the device which to me seems dirty and bad :)
is there a better way to do this?
I tried looking at all the methods of BluetoothDevice but none seemed to help - is the name really the best way to do it?
I saw that in some places people say that I should use UUIDs but that is used to open the socket to the device once I have it:
_socket = myDevice.createRfcommSocketToServiceRecord(MY_UUID);
is there a better way to do it?

Devices of the same kind/functionality and/or brand will usually have a similar name. For example, all RN-41 devices from Roving Networks have the following name:
FireFly-XXXX
where XXXX is the last 4 digits of the device's address. That means you can use the following to connect to any of them:
if (device.getName().startsWith("FireFly-")) {
this.myDevice = device;
break;
}
This is exactly what I do in my app and haven't found any more reliable/consistent way to do it. As a generalization, you should be able to use a regular pattern if the name in the devices you are interested in is any more complex than the example above.

You can use myDevice.getAddress() to get the bluetooth device address and compare, it will always be unique (unlike name)

You can also use BluetoothDevice.getBluetoothClass() for at narrowing down which devices might be relevant.
BluetoothClass.getMajorDeviceClass() will tell you roughly what kind of device it is - a phone, a computer, an audio or video device, or whatever.
BluetoothClass.hasService() further specifies some capabilities of the device.
Within each of the major classes, some minor classes are defined - what kind of computer / audio-video device / phone / health equipment etc. it is.
Also, on recent versions of the Android platform (API level 15+), you can query for the service records of a device, without having to connect to it. See BluetoothDevice.fetchUuidsWithSdp() and BluetoothDevice.getUuids().