Signal Strength Detector – The Results

First off, we would like to take the time to thank everyone who has gone ahead, downloaded, installed, and submitted your results using Signal Strength Detector. This will allow us to greatly improve how we handle signal strength calculations across a broad spectrum of devices. If you have not already, please do so, especially if you have a WiMAX, LTE, HSPA+, or other 4G device. For those without access to the Android Market the apk file is available for download here. Source code is also freely available under the Apache 2.0 license on GitHub.

For the programmers and more technologically inclined individuals here are the current Signal Strength Detector Results in the form of a zip file, which contains numerous text files one for each submission. It will be updated from time to time, and if it ever gets too out-of-date just remind us to update it.

Simply put, the results are horrifying! OEM has managed to change just about everything, whether it is the addition of new system services for WIMAX (and in the case of HTC, multiple services), or changing the values of constants that are actually part of the API! On Google Code issue 16862 points out that on the Samsung Galaxy S2 line the method SignalStrength.getGsmSignalStrength() always returns an invalid integer, and that the only solution is to use a proprietary, less-accurate, getGsmSignalBar() method. Or on the Samsung Galaxy Indulge R910 the constant NETWORK_TYPE_LTE has a value of 12 when the official API clearly states that its value should be 13.

All in all this spells headache for any developer, and for us with an application like StatusBar+ more frustration. It is bad enough that Android does not have an official API for LTE, W-CDMA, or WiMAX but as if that was not painful enough OEMs have taken it upon themselves to change what APIs we do have!

6 thoughts on “Signal Strength Detector – The Results

  1. I have been browsing your posted results in I want to make sure I am interpreting them right.

    1) Do I understand correctly that all the values reported under the FIELDS heading are the benchmark values your own app harvests or calculates, which are supposed to be the “right” values? And the values reported under the METHODS heading are what the android.telephony API calls actually return?

    2) If this is the case, I think you have a bug in the FIELDS value you are reporting for mBaseStationLongitude. The values you report are not within the valid range for this method. In all the examples I checked, the test phones return a valid and reasonable value for getBaseStationLongitude(), but your mBaseStationLongitude value is always out of range.

    It is easy to transform the values of getBaseStationLongitude() and getBaseStationLatitude() to decimal degrees. Just convert the int to a float and divide by 14400. (Each integer increment of 1 represent .25 arc seconds, so there are 14400 per degree.) The valid range for getBaseStationLongitude() is -2592000 to 2592000. The valid range for getBaseStationLatitude() -1296000 to 1296000.

    Other than that quibble, this is very useful data.

    • Dear Ross,

      The FIELDS values are NOT what our app calculates. The source code on GitHub explains more, but all we do is use reflection in Java to access hidden fields and methods within the SignalStrength class. We do NOT alter those values in any way.

      You are correct in saying that they contain bugs, that is the whole point of Signal Strength Detector. There are too many devices out today with broken APIs thanks to OEM mistakes (or intentional modifications). We put that app out to help us alleviate the issues associated with calculating signal strength.

      As for base station data I cannot vouch for that accuracy or the functionality of those APIs, as the name implies, Signal Strength Detector was designed solely for SignalStrength calculation. The other data was collected purely for comparison purposes, and perhaps to catch something out of the ordinary.

      Otherwise, glad the data could be of use.



      • Thanks for the clarification. BTW, I will install your Signal Strength Detector on my old Samsung Epic 4G, but I am especially interested in the newer generation of LTE-capable phones, and what they are reporting for LTE signal strength. Have you collected any samples from the Galaxy S 3 models, for example? The I downloaded seems a little stale.

  2. No, we mostly get repeats these days from WiMAX devices that we cannot support. WiMAX doesn’t work over Telephony, it has its own system service (or on HTC two system services). Nothing from the Galaxy S3 either, but it should behave like previous Galaxy S devices (Samsung’s APIs are not consistent with specifications but at least consistent with each other devices).


  3. Well I did install SIgnal Strength Detector on my Epic 4G. Ran it. It got to its main screen and showed the message that the listening had completed. Then it hard-crashed the phone so I had to power-up again. This happened three times in a row. So I must uninstall it. Sorry.

    I do appreciate your work, though. Are you the same Tom who commented on this issue at Google: ?

  4. One issue with Signal Strength Detector is that it tries to execute EVERY method. It catches Throwable, so technically ALL Exceptions and Errors. However, OEMs add APIs to Telephony that do some SERIOUS insecure things. For example, I don’t include EVERY result from HTC devices because even without permission you can obtain cell #, MEID, SIM serial, and control the current state of the radio (i.e. force CDMA over LTE, dispatch a call event without making a call, etc). Doing this repeatedly often crashes the Telephony system service, and this in turn crashes the OS. Nothing I can do about that.

    And I didn’t see a Tom who commented on that issue but probably not.


Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>