Join FlipAndroid.COM Telegram Group: https://t.me/joinchat/F_aqThGkhwcLzmI49vKAiw


El permiso ACCESS_COARSE_LOCATION da una precisión de torre celular en Android

Estoy haciendo algunas pruebas con la función requestLocationUpdates() desde FusedLocationApi . Estoy utilizando PRIORITY_BALANCED_POWER_ACCURACY . Una precisión de bloque de ciudad está bien para mí.

Cuando solicito el permiso ACCESS_FINE_LOCATION , obtengo alrededor de una precisión de 100m, lo cual es genial con GPS desactivado. Como no necesito una precisión de GPS sino una precisión de bloque de ciudad, me gustaría solicitar sólo el permiso ACCESS_COARSE_LOCATION . Sin embargo, cuando solicito el permiso ACCESS_COARSE_LOCATION , obtengo una precisión de 2 km. Parece que el dispositivo ya no utiliza el permiso Wifi y sólo una torre celular de precisión.

  • ¿Cuál es el color predeterminado para el texto en textview?
  • Android - Reproducción de mp3 desde byte
  • Limpieza de los permisos de Android no utilizados
  • ¿Por qué el lienzo no es del mismo tamaño que la vista en onDraw? (Androide)
  • El primer fotograma del vídeo de fondo no se muestra en Android
  • FragmentPagerAdapter getItem no se llama
  • ¿Cómo puedo tener una mejor precisión con el permiso ACCESS_COARSE_LOCATION ?

    Nota: el GPS está desactivado en mi dispositivo de prueba.

  • Dibuja un círculo en Android MapView
  • Cómo terminar todas las actividades y cerrar la aplicación en android?
  • Java.lang.IllegalStateException: Fragmento ya agregado
  • ¿Sobreestablece la fuente de mosaico MapView?
  • El controlador no pudo establecer una conexión segura con SQL Server mediante el cifrado de Secure Sockets Layer (SSL)
  • ¿Por qué no puedo importar servicios de Google Play a eclipse?
  • 2 Solutions collect form web for “El permiso ACCESS_COARSE_LOCATION da una precisión de torre celular en Android”

    Este es un problema interesante, y yo tenía la impresión de que usar ACCESS_COARSE_LOCATION usaría WiFi, ya que eso es lo que dice la documentación.

    La documentación de ACCESS_COARSE_LOCATION indica:

    Permite que una aplicación acceda a una ubicación aproximada derivada de fuentes de ubicación de red, como torres de celulares y Wi-Fi.

    Por lo tanto, lo pongo a prueba, y los resultados son sorprendentes.

    Aquí está el código que usé para probar con:

     public class MainActivity extends Activity implements GoogleApiClient.ConnectionCallbacks, GoogleApiClient.OnConnectionFailedListener, LocationListener { LocationRequest mLocationRequest; GoogleApiClient mGoogleApiClient; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); buildGoogleApiClient(); mGoogleApiClient.connect(); } @Override protected void onPause(){ super.onPause(); if (mGoogleApiClient != null) { LocationServices.FusedLocationApi.removeLocationUpdates(mGoogleApiClient, this); } } protected synchronized void buildGoogleApiClient() { Toast.makeText(this,"buildGoogleApiClient",Toast.LENGTH_SHORT).show(); mGoogleApiClient = new GoogleApiClient.Builder(this) .addConnectionCallbacks(this) .addOnConnectionFailedListener(this) .addApi(LocationServices.API) .build(); } @Override public void onConnected(Bundle bundle) { Toast.makeText(this,"onConnected",Toast.LENGTH_SHORT).show(); mLocationRequest = new LocationRequest(); mLocationRequest.setInterval(10); mLocationRequest.setFastestInterval(10); mLocationRequest.setPriority(LocationRequest.PRIORITY_BALANCED_POWER_ACCURACY); //mLocationRequest.setPriority(LocationRequest.PRIORITY_LOW_POWER); //mLocationRequest.setSmallestDisplacement(0.1F); LocationServices.FusedLocationApi.requestLocationUpdates(mGoogleApiClient, mLocationRequest, this); } @Override public void onConnectionSuspended(int i) { Toast.makeText(this,"onConnectionSuspended",Toast.LENGTH_SHORT).show(); } @Override public void onConnectionFailed(ConnectionResult connectionResult) { Toast.makeText(this,"onConnectionFailed",Toast.LENGTH_SHORT).show(); } @Override public void onLocationChanged(Location location) { Log.d("locationtesting", "accuracy: " + location.getAccuracy() + " lat: " + location.getLatitude() + " lon: " + location.getLongitude()); Toast.makeText(this,"Location Changed",Toast.LENGTH_SHORT).show(); } } 

    AndroidManifest.xml:

     <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" /> 

    Build.gradle:

     compile 'com.google.android.gms:play-services:7.3.0' 

    La primera prueba que hice fue con PRIORITY_BALANCED_POWER_ACCURACY , y no WiFi. Tenga en cuenta que también deshabilité Always Allow Scanning , ya que indica:

    Permita que Google Location Service y otras aplicaciones busquen redes Wi-Fi, incluso cuando Wi-Fi está desactivada

    Por lo tanto, que sin duda sesgar los resultados si se habilitó.

    Tenga en cuenta que también tenía el modo de ubicación establecido en modo de ahorro de batería para todas las pruebas, por lo que la radio GPS estaba apagado todo el tiempo.

    Estos son los resultados de PRIORITY_BALANCED_POWER_ACCURACY , ACCESS_COARSE_LOCATION y no WiFi:

     accuracy: 2000.0 lat: 37.78378378378378 lon: -122.40320943772021 

    Por lo tanto, dice 2000 metros de precisión, y aquí está lo lejos que las coordenadas reales son, la flecha verde muestra dónde estoy en realidad:

    Introduzca aquí la descripción de la imagen

    Entonces, habilité WiFi, y corrí la prueba otra vez, y sorprendentemente, los resultados eran exactamente iguales!

     accuracy: 2000.0 lat: 37.78378378378378 lon: -122.40320943772021 

    Luego cambié a LocationRequest.PRIORITY_LOW_POWER en el LocationRequest mientras mantenía android.permission.ACCESS_COARSE_LOCATION en AndroidManifest.xml.

    No wifi:

     accuracy: 2000.0 lat: 37.78378378378378 lon: -122.40320943772021 

    Con WiFi:

     accuracy: 2000.0 lat: 37.78378378378378 lon: -122.40320943772021 

    ¡Los resultados eran exactamente iguales otra vez! El uso de PRIORITY_LOW_POWER tuvo los mismos resultados que el uso de PRIORITY_BALANCED_POWER_ACCURACY , ya que el estado WiFi no parecía tener ningún efecto sobre la exactitud de las coordenadas.

    Luego, para cubrir todas las bases, cambié de nuevo a LocationRequest.PRIORITY_BALANCED_POWER_ACCURACY y cambié el AndroidManifest.xml a ACCESS_FINE_LOCATION :

     <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" /> 

    Primera prueba, sin WiFi:

     accuracy: 826.0 lat: 37.7825458 lon: -122.3948752 

    Por lo tanto, dice la precisión de 826 metros, y aquí está lo cerca que estaba en el mapa:

    Introduzca aquí la descripción de la imagen

    Luego, me encendido WiFi, y aquí está el resultado:

     accuracy: 18.847 lat: 37.779679 lon: -122.3930918 

    Es literalmente lugar, como se puede ver en el mapa:

    Introduzca aquí la descripción de la imagen

    Parece que importa menos lo que usas en tu LocationRequest en el código Java, y más qué permiso usas en AndroidManifest.xml, ya que los resultados aquí muestran claramente que al usar ACCESS_FINE_LOCATION , tener la radio WiFi activada o desactivada hizo un enorme Diferencia en la exactitud, y era también más exacta en general.

    Ciertamente, parece que la documentación es un poco errónea, y que al usar android.permission.ACCESS_COARSE_LOCATION , tener la radio WiFi activada o desactivada no hace ninguna diferencia cuando su aplicación es la única que realiza solicitudes de ubicación.

    Otra cosa que la documentación indica es que el uso de PRIORITY_BALANCED_POWER_ACCURACY le permitirá a su aplicación "piggy-back" en las solicitudes de ubicación hechas por otras aplicaciones. De la documentación:

    A ellos sólo se les asignará la culpa por el intervalo establecido por setInterval (largo), pero todavía puede recibir ubicaciones activadas por otras aplicaciones a una velocidad hasta setFastestInterval (largo).

    Así que si el usuario abre Google Maps, de acuerdo con la documentación de su aplicación puede obtener una ubicación más precisa en ese momento. Esa es una de las principales ventajas de usar el nuevo Fused Location Provider en lugar de las API más antiguas, ya que disminuye la cantidad de drenaje de la batería de tu aplicación sin mucho trabajo de tu parte.

    Edit: realicé una prueba de esta funcionalidad, para ver qué sucedería mientras utilizaba ACCESS_COARSE_LOCATION .

    Primera prueba: ACCESS_COARSE_LOCATION , PRIORITY_BALANCED_POWER_ACCURACY y WiFi en:

     accuracy: 2000.0 lat: 37.78378378378378 lon: -122.38041129850662 

    Eso me colocó en el agua, muy lejos de mi ubicación actual. Luego, salí de la aplicación de prueba, lanzó Google Maps, que me ubicó exactamente donde estoy, luego volvió a lanzar la aplicación de prueba. La aplicación de prueba no pudo volver a la ubicación desde Google Maps y el resultado fue exactamente el mismo que antes.

     accuracy: 2000.0 lat: 37.78378378378378 lon: -122.38041129850662 

    He vuelto a probar esto unas cuantas veces, sólo para estar seguro, pero parece que usar ACCESS_COARSE_LOCATION también deshabilita la capacidad de las aplicaciones para "piggy-back" en las ubicaciones obtenidas por otras aplicaciones.

    Parece que el uso de ACCESS_COARSE_LOCATION en AndroidManifest.xml paraliza la aplicación en términos de obtener datos de ubicación precisa.

    En conclusión, lo único que realmente puedes hacer es perfeccionar la mejor combinación de configuraciones que funcionan para ti y tu aplicación, y espero que los resultados de esta prueba puedan ayudarte a tomar esa decisión.

    Cuando solicita el permiso ACCESS_COARSE_LOCATION, el cliente de ubicación fusionada le dará una precisión de bloque de ciudad, ese es el comportamiento deseado y está escrito en la documentación. Echa un vistazo aquí en "Especificar permisos de la aplicación"
    Lo que puedo sugerir es que utilice el proveedor de ubicación normal de Android (no fusionado ubicación) y tratar de acceder al proveedor de red. Debe darle la exactitud de WIFI.

    FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.