Obsolete
Status Update
No update yet.
Comments
en...@google.com
ze...@skuza.net
Argh....with this bug there is absolutely no way to determine if the user has changed changed the panning of the map....I need a way to determine this so that i can allow the user to reset the map to it's original view. Please fix this ASAP.
ch...@gmail.com
I have another example regarding the problematic accuracy of moveCamera/animateCamera.
When you use CameraUpdateFactory.newLatLngBounds(), moveCamera and animateCamera result in different values in map.getProjection().getVisibleRegion().latLngBounds.
LatLngBounds bounds = new LatLngBounds(new LatLng(40.70798493778415, -74.01434069136418), new LatLng(40.72072004852845, -73.99760391411343));
if (animate) {
map.animateCamera(CameraUpdateFactory.newLatLngBounds(bounds, 0),
} else {
map.moveCamera(CameraUpdateFactory.newLatLngBounds(bounds, 0));
}
map.getProjection().getVisibleRegion().latLngBounds :
after animateCamera -
LatLngBounds{southwest=lat/lng: (40.70711197865251,-74.01539381593466), northeast=lat/lng: (40.72159253556309,-73.99655096232891)}
after moveCamera -
LatLngBounds{southwest=lat/lng: (40.70798500292429,-74.01539381593466), northeast=lat/lng: (40.72071968970514,-73.99655096232891)}
This is pretty important for my design as im calculating a search radius (Vincenty’s formula) by the bounds of the map. appreciate if you could confirm the accuracy of those 2 APIs.
When you use CameraUpdateFactory.newLatLngBounds(), moveCamera and animateCamera result in different values in map.getProjection().getVisibleRegion().latLngBounds.
LatLngBounds bounds = new LatLngBounds(new LatLng(40.70798493778415, -74.01434069136418), new LatLng(40.72072004852845, -73.99760391411343));
if (animate) {
map.animateCamera(CameraUpdateFactory.newLatLngBounds(bounds, 0),
} else {
map.moveCamera(CameraUpdateFactory.newLatLngBounds(bounds, 0));
}
map.getProjection().getVisibleRegion().latLngBounds :
after animateCamera -
LatLngBounds{southwest=lat/lng: (40.70711197865251,-74.01539381593466), northeast=lat/lng: (40.72159253556309,-73.99655096232891)}
after moveCamera -
LatLngBounds{southwest=lat/lng: (40.70798500292429,-74.01539381593466), northeast=lat/lng: (40.72071968970514,-73.99655096232891)}
This is pretty important for my design as im calculating a search radius (Vincenty’s formula) by the bounds of the map. appreciate if you could confirm the accuracy of those 2 APIs.
[Deleted User] <[Deleted User]>
any news regarding this issue ?
js...@gmail.com
I can share my thoughts about it.
LatLng is keeping doubles, when these are sent via IPC, they are flattened to floats, because there is no writeDouble:http://developer.android.com/reference/android/os/Parcel.html#writeFloat%28float%29 .
When going back, you lose precision and thus errors on 4-5th decimal place.
If I'm correct here, this can be hard (if possible) to fix without breaking compatibility.
LatLng is keeping doubles, when these are sent via IPC, they are flattened to floats, because there is no writeDouble:
When going back, you lose precision and thus errors on 4-5th decimal place.
If I'm correct here, this can be hard (if possible) to fix without breaking compatibility.
ri...@gmail.com
If you're right then compatibility doesnt have to be broken in order to pass a more accurate LatLng value in many other parcelable types which are not float. This option can be added and not replace the current one.
I any case this issue is really annoying and i hope someone from google can take a look at it. Thanks.
I any case this issue is really annoying and i hope someone from google can take a look at it. Thanks.
im...@gmail.com
If I'm right then you are also right. ;)
Double values in LatLng could be sent using writeLong after converting them using Double.doubleToLongBits (http://docs.oracle.com/javase/7/docs/api/java/lang/Double.html#doubleToLongBits%28double%29 ) and converted back to double in Google Play Services app.
Double values in LatLng could be sent using writeLong after converting them using Double.doubleToLongBits (
Description
discussions please visit:
- Steps to reproduce the problem:
================================
My Wireless AP is configured to authenticate users using a RADIUS server. this RADIUS server authenticates users using a RSA ACE SecurID authentication server which requires users to enter one time passwords from their hardware RSA SecurID or from thier RSA Soft token. To facilitate this, RADIUS servers is configured for EAP-PEAP/EAP-GTC protocols for 802.1x
In my Google Nexus S running Android 2.3.4, I configure wifi network using following steps:
1)Menu->Settings->Wireless&Networks->Wifi-Settings->Turn on Wifi
Now the Android will scan for broadcasting SSIDs and lists then in Wifi settings page.
2)Tap on the SSID that I configured on my Wireless AP
Now Android will show SSID configuration dialog to let user enter 802.1x settings and credentials for authenticating with SSID
3)In 802.1x configuration dialog do following:
- EAP Method: PEAP
- Phase 2 Authentication: GTC
- CA Certificate: Select the CA certificate which issued certificate to your RADIUS server
- User Certificate: leave it at its default value
- Identity: Enter your username on RSA Ace Server
- Anonymous Identity: either leave it blank or enter 'anonymous' without quotes
- Password: if you are using soft token, enter the passcode displayed in the soft token or if you are using hardware token enter your RSA PIN and token code displayed on the hardware token
4)Now click on connect.
5)if prompted for credential storage password, enter it as you are trying to use CA certificate that is stored in credential storage on Android
Android authenticates with the SSID and I was able to connect to network. everything works perfect till this point.
6)Now Turn off Wifi and wait for few mins.
7)Turn on Wifi and wait for Android to automatically initiate connection attempt to your Wifi SSID as Android already has settings for your Wifi network. If Android automatically doesn't initiate connection, tap on your SSID so that Android initiates connection to your SSID.
- What happened?:
===============
After this, Android Wifi SSID status stays at 'Connecting' for a while and then goes into 'Remembered, Disabled' state.
If I tap on SSID again and then tap on 'Connect', same status as mentioned above line is seen
When look at RSA ACE server's authentication log, I see lot of attempts from Android phone trying to authenticate using same token code that I entered in step-3.
Where as EAP-GTC passwords shouldn't cached and shouldn't be reused in subsequent authentication attempts, it appears that Android is infact caching the OTP(one time password) token code entered in step-3 and using it for future connection as Android does it for usual username/password based authentication
- What you think the correct behavior should be:
===============================================
here are the issues in the order of their severity:
Issue-1: If EAP-GTC is being used for authentication, Android should prompt user for password for every authentication attempt with same SSID. As Android is using cached token code, my account on RSA ACE server is getting locked because of password replay attack by my Android phone. I need to call my RSA ACE server admin to unlock my account just because I am using Android.
Issue-2: And the password prompt should come on the screen, no matter in which screen user is in. i.e if phone is displaying some app's ui and at the same time Android requires password to connect to this previously known SSID, the password dialog should appear on top any existing UI.
If you need a perfect example of how password prompt should look like, look at the way iOS asks for App Store password while installing/upgrading an App. having said that, I am not a fan of iOS :=). But, they implemented password prompt very well.
-Device where Issue is Reported:
================================
Google Nexus S I9023 running Android 2.3.4