Alright guys, I finished my tests. Warning: Tech-talk ahead!
As far as I can tell, there are three classes that have access to the phone number:
The class BindMobileActivity contains an Activity that populates a View, including an EditText of the phone number. This however only occurs if the phone number starts with the country code +86 (China). The following paragraph therefore only applies to Chinese phone numbers.
The mentioned EditText can be accessed by another class, ImRegisterWizardView2 (com\jb\gosms\ui\contacts), which provides a static private method named "EditText I(ImRegisterWizardView2 imregisterwizardview2)" to get the EditView. At first sight, there is no method that accesses "EditText I(ImRegisterWizardView2 imregisterwizardview2)". However, after checking for reflection calls, I found two classes named "bn.java" (com\jb\gosms\ui\contacts) and "br.java" (com\jb\gosms\ui\contacts). "bn.java" enables the EditText while "br.java" disables the EditText. Other than that, there are no calls to the mentioned methods.
I haven't taken the time to find out what BindMobileActivity specifically acomplishes, but I assume it has something to do with some sort of registration process for Chinese users. If anybody knows more, please tell us about it.
Looking at the source code of BindMobileActivity.java and its related files, I consider "com\jb\gosms\goim\ui\BindMobileActivity.java" to be safe
c.java is a class that handles MMS messages. To be precise, it handles http requests (GET /SET) related to sending MMS.
It contains a protected static method named "Code(Context context, long l, String s, byte abyte0, int i, boolean flag, String s1, int j, boolean flag1)" which attaches several headers to a http connection. One of these headers is a string containing the phone's number.
This made me suspicous at first, however upon closer inspection, I realised that this header is part of the standard MMS headers and stores the sender's phone number. The HTTP server, which is passed as the "String s" parameter, is actually the MMS proxy server provided by the Android system. Judging by the rest of the code, I have serious doubts that this method could be used to transmit the phone's number to the developer, especially since the rest of the method deals with MMS releated header data.
I consider this method safe
The third class, jr.java, is rather simple to understand. There are two methods that handle the phone's number, Code() and Code(String s). Code() actually just saves the phone's number to a local private variable named "Z". The second method Code(String s) compares a given string s to Z and returns true if both values are the same. This could be used to brute-force the phone number by using the reflection API. However, there are much easier ways to access the phone's number, making this approach impractical.
Therefore, I wouldn't call this class a possible security risk either.
Just to be on the safe side, I have double-checked the entire code for reflection calls. However only two calls related to the phone's number were made. Those two have already been discussed above (see BindMobileActivity) and do not pose a security risk.
In conclusion I have not found any sign that the phone's number is sent to the GoSMS developer or any other server beside the MMS proxy server.
I welcome everybody to check my analysis. If there are any mistakes, please let me know.
Oh, and before I forget: I used dex2jar-0.0.9.7 to convert the dex file to jar and used DJ Java Decompiler 3.12 to get readable java source files. I hope that method names are the same on all computers. If there are issues regarding file or method names, feel free to use the attached decompiled files (the jad files contain the java source code).