16

I need to send a USSD code containing a double value, that represents the balance account amount to be transferred. This value is composed by an integer number, and optionally a decimal separator and 2 more digits. My code looks as follows:

    double doubleValue = 0.70;
    String phoneNumber = "51234567", pincode = "1234";
    String ast = Uri.encode("*");
    String baseUssd = ast + "234" + ast + "1" + ast + phoneNumber + ast + pincode + ast;
    StringBuilder builder = new StringBuilder();
    builder.append(baseUssd);
    builder.append(doubleValue); //i.e: 1.35, 0.80
    builder.append(Uri.encode("#"));
    Intent intent = new Intent(Intent.ACTION_CALL, Uri.parse("tel:" + builder.toString()));
    startActivity(intent);

My phone treats the doubleValue as 135, 080, etc. ignoring the dot separator character. I hope the final code includes "dot", allowing send the decimal value. Someone solved this problem?

Roberto Tellez Ibarra
  • 2,146
  • 3
  • 18
  • 34

2 Answers2

7

The Java code shown works fine of course assuming that doubleValue is a float or a double.

As suggested here the Intent is handled by OutgoingCallBroadcaster.processIntent() which processes the String given in the Intent by calling PhoneNumberUtils.convertKeypadLettersToDigits() and PhoneNumberUtils.stripSeparators().

The latter one strips everything except numbers, *, #, + and the WILD, WAIT and PAUSE symbols.

This is where your decimal separator is lost.

So either the separator should be escaped to a specific numerical value or substituted by one of the accepted symbols to actually leave your phone and reach the receiver.

Whoever is responsible for the receiving end can probably advice you on properly formatting your decimal number.

Community
  • 1
  • 1
Markus Kauppinen
  • 3,025
  • 4
  • 20
  • 30
  • Thanks Markus. I can't tell if the "receiver" answer me, I could try anyway. Can I replace the `OutgoingCallBroadcaster` by my own? – Roberto Tellez Ibarra Jul 06 '15 at 13:31
  • I don't think that replacing `OutgoingCallBroadcaster` is realistic. But if you look at the comments in [link](https://android.googlesource.com/platform/packages/services/Telephony/+/kitkat-dev/src/com/android/phone/OutgoingCallBroadcaster.java#48) it's said that it will receive the `CALL` intent (from your application) and after doing what it does it broadcasts an `ACTION_NEW_OUTGOING_CALL` intent. You could apparently receive the the `ACTION_NEW_OUTGOING_CALL` intent with a `BroadCastReceiver` and still change the intent details including the phone number that includes your USSD command. – Markus Kauppinen Jul 06 '15 at 14:13
  • See e.g. [this](http://stackoverflow.com/questions/9569118/how-do-you-receive-outgoing-call-in-broadcastreceiver#25328256) for an example of receiving the outgoing call intent. See [this blog post](http://android-developers.blogspot.fi/2011/01/processing-ordered-broadcasts.html) for example code of actually modifying the phone number inside the intent. So looks like there's a chance that you could intercept the outgoing call and put the decimal separator back where it belongs unless it's just against some ITU standards and whatnot and still gets stripped later on in the process. – Markus Kauppinen Jul 06 '15 at 14:13
6

Thinking about the way the pinpad, which my bank sent me, works, you always have to enter the two digits after the decimal point and the formatting on the display deals with the position of the point.

So if i enter "1", it is interpreted as 0.01. Similarly "1023" would be 10.23.

I think the same approach could work nicely for you. So 1.23 is entered as "123" and 0.80 as "80"

I can't see a reference that limits the characters to 0-9#* but all the examples follow this format. However, your example starts *234, which seems to fit this rule in the specification

Case a) 1, 2 or 3 digits from the set (*, #) followed by 1X(Y), where X=any number 0-4, Y=any number 0-9, then, optionally "* followed by any number of any characters", and concluding with # SEND: This case is reserved for HPLMN use. When a serving network receives such a message from a visiting subscriber, it shall pass the USSD message directly to the HPLMN. If it receives it from a home subscriber, it is up to the network to decide whether to treat it locally or to pass it to the HLR

http://www.etsi.org/deliver/etsi_ts/100600_100699/100625/07.00.00_60/ts_100625v070000p.pdf

In general, I am not sure the HPLMN (Home Public Land Mobile Network) or HLR (Home Location Register) would expect the extra characters, even though the whole character set and even other character sets are allowed in the USSD protocol.

formica
  • 934
  • 1
  • 8
  • 16