Trying to initiate an intent to send an SMS to multiple recipients with the following code:
Intent smsIntent = new Intent(Intent.ACTION_SENDTO, Uri.fromParts(
"sms", destination, null));
However in the destination string say I have "555-555-5555,555-555-5556". The comma delimiter is working fine on a Samsung vibrant. However, this will not work on a nexus 1. On the nexus one i need to use a semicolon as the delimiter and then it works. On the nexus one, if I use commas as the delimiter, it only picks up the last phone number. If I use the semicolon, the nexus one picks up all the phone numbers however, it then breaks the vibrant. With the semicolon, the vibrant does not pick up any of the phone numbers. Any insights?
You should file feature request in android
for the public telephony api to standardize this kind of stuff.
Until now (Gingerbread 2.3.3) there is no "default character" or api do discover what is the correct for each rom.
Anyway, I suggest that you ask people do test in different roms and create switch cases in your app. It will not work in all of them, but could work in most of.
Semicolon works for other than samsung and Comma works for Samsung devices. Just put a check for:
String manufactures = android.os.Build.MANUFACTURER;
to achieve the same functionality for both samsung vs others.
Related
In Android you can set a username for the device. I've set up a few devices where it asked me for my first name and last name. I was wondering how to retrieve this. In iOS you can get a name like "Kate's iPhone" for the device name which is what I want to do on Android. Additionally in a game I'd like to fill in the Characters name with the persons name. So I could essentially say String.format("Hello, %s", getUsername); Is this possible in Android down to API 10? The only thing I've found is UserManager with a getUserName() method, but it is only available at API level 17 which I think lines up with when Android allowed tablets to have multi user support... so I'm not sure it will actually give a valid response on a phone. Does anyone have any ideas?
I am not looking for device name (e.g. Nexus 7, Nexus 4, Samsung Galaxy S5).
This works on a real phone, in an Emulator you will get an empty String.
BluetoothAdapter myDevice = BluetoothAdapter.getDefaultAdapter();
String deviceName = myDevice.getName();
Toast.makeText(this, "Phone "+deviceName, Toast.LENGTH_LONG).show();
Remember to add the permission to the Manifest:
<uses-permission android:name="android.permission.BLUETOOTH"/>
I have a technical issue that I can't resolve because the problem only happens on the other side of the planet that I'm on.
So I am hoping someone with a lot more Experience with these technologies can suggest an alternate approach or path to take in order to rectify it, or possibly right out "RECOGNIZE" the source of the problem.
THE SCENARIO :
I have developed an application for the Samsung Gear2 that sends SMS messages using its host companion android application.
In all tests I perform with the app pair, everything works as expected.
Messages are sent by the android device's SMS manager and received by the recipient no problem, even when adding and removing the leading 1.
10 and 11 digit numbers to and from the USA, with and without the leading + sign all pass.
However, when sending the apps to Samsung for review and testing, they keep having problems sending certain numbers. As far as I can tell the only thing different between the numbers that send and the numbers that fail is the fact that the first has a leading 0 and the second does not.
This would have to be coupled with the fact that they are testing this functionality
in a different Continent/Country than the 1 where my tests are being done(USA).
As my tests succeed to send and receive the messages regardless of whether
the number is a 10 digit version or 11 digit version of the same number.
Also discrepancies surfacing from the use of different Carriers (possibly Telecom in Asia) other than the one that I am testing with(Bell - USA)...
To be clear, I am simply composing messages via the Gear2 app and sending it to the android device via Samsung's Accessory Protocol which works flawlessly.
From there I use the basic implementation of the standard
Android's SMSManager
getDefault()
and
sendTextMessage(String destinationAddress, String scAddress, String
text, PendingIntent sentIntent, PendingIntent deliveryIntent)
with all null values exept the "destinationAddress","text",
and the "sentIntent".
THE QUESTION(s) : in order of most to least important
1. IS THERE a specific "routine" SMS app developers use to maximize the
success rate
of sent sms messages no matter what Country or Carrier the user sends the message from or to, and no matter if the entered number contains the leading exit and Country codes?
(ie: Adding or removing a plus(+) sign, per-examining the Locale
being used and adjusting the number accordingly using some sort of
"SMS Numbering Standard", Altering the Service Center Address / SMSC
Address (AT+CSCA), ect...)?
2. IS THERE some sort of information source detailing general "GOTCHAS" to look for
dependent upon the various Cell/SMS service providers/Carriers? (at least 4 that I know of).
3. Why would Android's SMSManger report "SMS Sent" if the message wasn't actually delivered.
NOTE: I realize that one can also listen for the "second" broadcast android sends
confirming that the message was "actually" received by the recipient, but that raises questions concerning how to rectify that situation, if it's at all rectifiable (at least from a programmatic perspective.)
4. Should my app, which is actually a Samsung Gear2 app integrated with an android app,
and merely delegates the responsibility of sending the messages to the android devices SMSManager, be held responsible for the message not being sent?
NOTE: I can't help but feel that Samsung is requiring me to handle
issues outside the scope and unrelated to the apps intended
functionality, Albeit , I do understand that at least part of the
issue has to fall back on me by Default, being the nature of the Gear2
apps dependance on the android device to complete the intended action
started by the Gear2 app, but how far must I go to ensure the standard
SMS abilities of a users android device beyond giving helpful feedback
as to what the underlying problem may be. I have to assume this
problem would exist using the device itself to compose the message
instead of the Gear2 app, given the exact same address/number .
5. Assuming that the app is being tested in Asia (South Korea, Samsung's Headquarters)... And assuming that the carrier being used to test SMS is SK Telecom
(Which I think is South Korea's top Carrier)...
Is it Mandatory to start all numbers with a zero in order to successfully send an SMS within the same Country? And if so is that the same in all Countries besides the USA and Canada(Which seem to work either way)?
6. Is this a common issue to deal with generally when developing sms applications, or can I single this particular situation out from the rest based on the unique variables introduced by Samsung's over diligent testing practices along with there unfamiliar
Telephony Service Providers and even more unfamiliar Geo-location/Country-code and numbering schemes.
THE PROBLEM *(only happens during Samsung testing) :
TEST 1:
Send SMS from stored contacts with number 010-6627-xxxx (11 digits)
Result:
SMS is reported by android's SMSManager as sent. The recipient
immediately receives SMS message.
Conclusion:
SMS delivery success.
TEST 2:
Send SMS from manually entering number 10-6627-xxxx (10 digits) (same number as previous without first 0)
Result:
SMS is reported by android's SMSManager as sent. However, the
recipient never receives SMS message.
Conclusion:
?
Unable to duplicate this problem (at least not in the USA) as both :
11 digit numbers (leading 1) AND 10 digit numbers
(no leading 1)
Successfully send the message as expected.
The problem only happens during device testing/certification by Samsung's app testing
department, and seemingly only when manually entering the destination address/number.
Stored Contacts (for some reason) always work.
After being denied certification of an otherwise "GOOD TO GO APPLICATION" 3 times by Samsung for issues UN-recreatable in my own testing environment I find myself turning the good folks at SOF with this "HAIL MARY PASS".
I do not change anything at all about the numbers that are sent to the SMSManager, But I'm wondering if maybe THAT'S the problem.
EXTRA INFO :
All devices used are using android 4.2 and higher.
My tests were all done using T-Mobile Galaxy phones and sometimes google/Gmail/GoogleVoice
sms/mms service From North Fla. USA.
ON A SIDE NOTE ABOUT SAMSUNG...
Samsung's testers are very sparse with the details of their testing enviroment including what may possibly be the issue from their standpoint which is unfortunate because I'm becoming certain that this issue is Trivial at best and probably easily fixable with a basic understanding of your own Country/Carriers methods for sending successful SMS messages.
It seems they are not even making an effort to enlighten me or TO make any neccesary
adjustments to their test numbers as any user would do in order to have a successful result.
ANY INSIGHT INTO THIS ISSUE WHATSOEVER WOULD BE IMMENSELY APPRECIATED!!!
Interesting question. I understand that the Samsung testing process can be quite rigorous.
From reading your info .. have you tried including that leading "0" yourself? E,g when a person manually enters 10 digits without a leading 0, you detect it and add this "0" . Also, how are this digits entered on a gear 2 device ? Do you implement your own keypad and ensure it captures the right digits ?
I guess that would be a starting point ..
V.
When I test my application with the emulator I get the following message: "Mobile network not available". Ofcourse I don't expect it to actually call from the emulator, but I want some sort of confirmation that it works.
In my application I use an intent like:
Intent intent = new Intent(Intent.ACTION_CALL);
intent.setData(Uri.parse("tel:" + Uri.encode(input.getText().toString())));
context.startActivity(intent);
I also implement this <uses-permission android:name="android.permission.CALL_PHONE"/> in the manifest-file.
Why is this?
EDIT: Seems like this only was a problem when I used GenyMotion. With the regular simulator, the call simulation worked.
You have to check and update if it works. This is my assumption which may work since I have not tried it by myself.
Open another emulator and note down its port number and use something like this
callIntent.setData(Uri.parse("tel:5554")); // assuming the second emulator port number is 5554
I am assuming this because, there is no sim card inserted in the emulator so you cannot call any real life phone number. But it is actually possible to dial one emulator from another using its port number using built in dialer app.
I want to forward any calls received to another predefined phone number. I have searched forums and found some contradictory answers. so i m confused.
First I looked at this post https://stackoverflow.com/a/5735711 which suggests that it is not possible through android.
But another post has some solution. https://stackoverflow.com/a/8132536/1089856
I tried this code from second post, but i m getting the following error message: "Call Forwarding connection problem or Invalid MMI Code."
String callForwardString = "**21*5556#";
Intent intentCallForward = new Intent(Intent.ACTION_CALL);
Uri uri2 = Uri.fromParts("tel", callForwardString, "#");
intentCallForward.setData(uri2);
startActivity(intentCallForward);
Where 5556 is the number of emulator (for testing) where i want to forward call.
i think you need to try it on the device better than the emulator.
You are using DTMF codes, so i think you need network (on the actual device) rather than on the emulator.
Dial the same code "**21*5556#" on your emulator and check. It does not work either! Replace the 5556 with the phone number you want to forward the call to and then try it on phone.
Meaning, the DTMF codes would work only on mobiles not on emulators or tablets without SIM support.
EDIT:
you can find different call forwarding codes here.
Remove the "#" from Uri uri2 = Uri.fromParts("tel", callForwardString, "#");
if that do not work then try just *21*number#
I've observed this issue for years now, not knowing where it came from. I am concerned that this bug is still observable in the new versions of Android, in 2011, and I hope you can finally help me to fully understand it, if not solve it.
Let's consider the given (real) situation. Mister "A" is using a custom SMS/MMS app from Sony on his Xperia Arc (official 2.3.3). Mister B is using the android SMS/MMS stack app on his Milestone (Cyanogen 6.12, unofficial 2.2). Both of them use Android in French (if that matters).
When A sends a sms to B containing special characters like "ç", "ê", B receives a message with these characters replaced by a space. Characters like "é" are working fine though.
When B sends the sms to A, everything works fine.
When A sends this sms to himself, everything works fine.
Conclusion : this is not the mobile provider's fault since it works in one way and not the other.
So, I guessed at first that something was wrong with A's custom app. Replaced it with the apk from B's phone. Everything remained the same. I decompiled the app and I didn't find where the encoding of the sms string was done. I concluded the bug is not coming from the app, but from the way Android encodes the strings...
I ran another test :
I wrote an sms with only standard characters, something like 250 characters in 1.5 sms. Then, I append a "ç" to the sms.
On A's phone : the counter says it consumed 10 characters.
On B's phone : the counter says the sms now takes 3 sms : the string size doubled !
Conclusion :
On A's phone, the default charset includes "ç".
On B's phone, when "ç" appears, the charset changes and each character needs then twice the original space.
(Or am I missing something ?)
Questions :
Why different version of Android aren't using the same default charset ?
On Android, are these default charset depending on the rom, for example ?
Can we configure/change these charset somewhere (in the menu or directly on a rooted phone) ?
Is there another easy way to fix this ?
Any help, explanation or experience is welcome :)
You are suffering from encoding problems. From the description it looks like 'A' is sending data in one charset and not including information about what charset that is. The root cause is that to pass extended (non-ascii) characters between two systems they have to agree on an encoding to use. If you are restricted to 8 bit values then the systems agree to use the same codepages. In SMS there is a special GSM codepage for 7 or 8 bit encodings or UTF-16 can be used which uses 2 bytes to represent each character. What you see when you enter 250 characters followed by a single extended character shows you what is happening in the application. An SMS message is restricted to 140 octets. When you are using an 8 bit encoding your 250 chars fit into 2 messages (250 < 280) however once you added the "ç" the app changed to using UTF-16 encoding so suddenly all your characters are taking 2 octets and you can only fit 70 characters into a message. Now it takes 3.5 SMS messages to transfer the entire message.
On Android the decoding of the SMS message is part of the framework telephony code in SmsCbMessage.java. It works out the language code and encoding of the message body. If this is incorrect (the message was encoded with an english codepage but uses french extended chars) then you can get odd characters appearing.
You are right that this is not the mobile network at fault. I suspect it is phone A's messaging application although it is possible that Android is failing to correctly identify the encoding of a valid SMS. I wonder how it works between A and an iPhone or some other manufacturers device.
I have encountered the same problem when I had to show a few special characters in an sms unicode app. The method I used was take the string that I need to send as sms, run it in a for loop to take each character , find its ascii code , use that integer value to encode that string using a delimiter. This string can be sent as sms, which needs to be decoded using the same delimiter that is used for sending, then convert each ascii code char in it to characters (language specific), form a string by appending the converted chars. This text will be same as the one that was sent as sms.
Regards