Comments for The Seven+ Project http://sevenplusandroid.org/blog The Official Blog of the Seven+ UI Cooperative Fri, 03 Aug 2012 00:26:50 +0000 hourly 1 http://wordpress.org/?v=3.4.1 Comment on Android Software Buttons by 김명진 http://sevenplusandroid.org/blog/2012/04/android-software-buttons/#comment-1040 김명진 Fri, 03 Aug 2012 00:26:50 +0000 http://sevenplusandroid.org/blog/?p=317#comment-1040 Hi I want this is ha...plese Hi I want this is ha…plese

]]>
Comment on StatusBar+ Roadmap by 김명진 http://sevenplusandroid.org/blog/2012/04/statusbar-roadmap/#comment-1039 김명진 Fri, 03 Aug 2012 00:25:27 +0000 http://sevenplusandroid.org/blog/?p=310#comment-1039 사고파요..ㅠ 사고파요..ㅠ

]]>
Comment on Signal Strength Detector – The Results by Tom http://sevenplusandroid.org/blog/2011/12/signal-strength-detector-the-results/#comment-1029 Tom Thu, 19 Jul 2012 19:09:22 +0000 http://sevenplusandroid.org/blog/?p=183#comment-1029 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. Tom 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.

Tom

]]>
Comment on Signal Strength Detector – The Results by Ross http://sevenplusandroid.org/blog/2011/12/signal-strength-detector-the-results/#comment-1028 Ross Thu, 19 Jul 2012 18:57:13 +0000 http://sevenplusandroid.org/blog/?p=183#comment-1028 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: http://code.google.com/p/android/issues/detail?id=22958 ? 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: http://code.google.com/p/android/issues/detail?id=22958 ?

]]>
Comment on Signal Strength Detector – The Results by Tom http://sevenplusandroid.org/blog/2011/12/signal-strength-detector-the-results/#comment-1027 Tom Thu, 19 Jul 2012 17:32:29 +0000 http://sevenplusandroid.org/blog/?p=183#comment-1027 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). Tom 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).

Tom

]]>
Comment on Signal Strength Detector – The Results by Ross http://sevenplusandroid.org/blog/2011/12/signal-strength-detector-the-results/#comment-1026 Ross Thu, 19 Jul 2012 17:11:56 +0000 http://sevenplusandroid.org/blog/?p=183#comment-1026 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 signal.zip I downloaded seems a little stale. 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 signal.zip I downloaded seems a little stale.

]]>
Comment on Signal Strength Detector – The Results by Tom http://sevenplusandroid.org/blog/2011/12/signal-strength-detector-the-results/#comment-1021 Tom Thu, 19 Jul 2012 15:14:48 +0000 http://sevenplusandroid.org/blog/?p=183#comment-1021 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. Best, Tom 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.

Best,

Tom

]]>
Comment on Signal Strength Detector – The Results by Ross http://sevenplusandroid.org/blog/2011/12/signal-strength-detector-the-results/#comment-1020 Ross Thu, 19 Jul 2012 14:21:12 +0000 http://sevenplusandroid.org/blog/?p=183#comment-1020 I have been browsing your posted results in signal.zip. 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. I have been browsing your posted results in signal.zip. 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.

]]>
Comment on Calculating Infinity by maryam http://sevenplusandroid.org/blog/2012/07/calculating-infinity/#comment-1010 maryam Sun, 08 Jul 2012 10:30:13 +0000 http://sevenplusandroid.org/blog/?p=377#comment-1010 Download Download

]]>
Comment on Connecting The Dots by URL http://sevenplusandroid.org/blog/2012/03/connecting-the-dots/#comment-996 URL Thu, 28 Jun 2012 08:38:17 +0000 http://sevenplusandroid.org/blog/?p=245#comment-996 <strong>... [Trackback]...</strong> [...] Read More Infos here: sevenplusandroid.org/blog/2012/03/connecting-the-dots/ [...]... … [Trackback]…

[...] Read More Infos here: sevenplusandroid.org/blog/2012/03/connecting-the-dots/ [...]…

]]>