Fix `robius-location` on Android so we can publish it to crates.io

[imunproductive]

Hey! Amazing library, I love it!
I am mainly interested in using this library in my crate, however I won't be able to post it on crates.io if it uses this crate using git.
Are there any plans on posting it to crates.io at all?

[kevinaboos]

Hi, thanks for the question! Yes, certainly we do plan to do so -- I had intended to publish it quite a while ago, but I got redirected to work on other topics. I intend to get back to this shortly, either this week or next, so your question is well-timed.

The primary blocker is that Android support sort of works. There is a problem that we have yet to solve, in which requesting the location on Android will sometimes fail and cause the application to crash. Other times it works, seemingly nondeterministically. So since I'm not yet sure how to fix that problem, I had been unwilling to publish it to crates.io.

[kevinaboos]

Here's the log detailing the problem.

dev.makepad.robius_demo_simple       D  src/app.rs:229:12 - Location requested. Waiting for updates...

java_vm_ext.cc:616] JNI DETECTED ERROR IN APPLICATION: JNI NewStringUTF called with pending exception java.lang.SecurityException: uid 10583 does not have android.permission.ACCESS_COARSE_LOCATION or android.permission.ACCESS_FINE_LOCATION.
java_vm_ext.cc:616]   at java.lang.Exception android.os.Parcel.createExceptionOrNull(int, java.lang.String) (Parcel.java:3272)
java_vm_ext.cc:616]   at java.lang.Exception android.os.Parcel.createException(int, java.lang.String) (Parcel.java:3256)
java_vm_ext.cc:616]   at void android.os.Parcel.readException(int, java.lang.String) (Parcel.java:3239)
java_vm_ext.cc:616]   at void android.os.Parcel.readException() (Parcel.java:3181)
java_vm_ext.cc:616]   at android.os.ICancellationSignal android.location.ILocationManager$Stub$Proxy.getCurrentLocation(java.lang.String, android.location.LocationRequest, android.location.ILocationCallback, java.lang.String, java.lang.String, java.lang.String) (ILocationManager.java:1274)
java_vm_ext.cc:616]   at void android.location.LocationManager.getCurrentLocation(java.lang.String, android.location.LocationRequest, android.os.CancellationSignal, java.util.concurrent.Executor, java.util.function.Consumer) (LocationManager.java:1069)
java_vm_ext.cc:616]   at void android.location.LocationManager.getCurrentLocation(java.lang.String, android.os.CancellationSignal, java.util.concurrent.Executor, java.util.function.Consumer) (LocationManager.java:971)
java_vm_ext.cc:616] Caused by: android.os.RemoteException: Remote stack trace:
java_vm_ext.cc:616] 	at com.android.server.location.LocationPermissions.enforceLocationPermission(LocationPermissions.java:139)
java_vm_ext.cc:616] 	at com.android.server.location.LocationManagerService.getCurrentLocation(LocationManagerService.java:891)
java_vm_ext.cc:616] 	at android.location.ILocationManager$Stub.onTransact(ILocationManager.java:578)
java_vm_ext.cc:616] 	at android.os.Binder.execTransactInternal(Binder.java:1518)
java_vm_ext.cc:616] 	at android.os.Binder.execTransact(Binder.java:1457)
java_vm_ext.cc:616] 
java_vm_ext.cc:616] (Throwable with no stack trace)
java_vm_ext.cc:616] 
java_vm_ext.cc:616]     in call to NewStringUTF

It's likely caused by the fact that the Manager::new() function on Android (more specifically, the request_authorization() fn) apparently does not wait to get a result from the requestPermissions JNI call before returning, which allows the codeflow to proceed with a subsequent call to a location-accessing function, e.g., start_updates().