Using Updated Version With @capacitor/geolocation Makes The App Crash #104
Comments
|
Can you provide a stack trace? |
|
Here's the stack trace: |
|
I have no idea why this is happening, and unfortunately I don't have time to look into it. Please let me know if you find the problem. If all else fails, you can use this plugin for both foreground and background location updates (simply omit the |
You should delete @capacitor/background-runner @capacitor/geolocation if you have them, I've had such problem, but my app couldn't build so I found out that those packeges are extra and I should get rid of them |
|
Any update on this? We kind'a want to use @capacitor-community/background-geolocation along side with @capacitor/geolocation. |
|
If you can locate the problem, I will release a fix. |
|
When the app is moved to the background, the background geolocation watch often stops. Occasionally, it continues running, but it is unreliable. The issue appears to be associated with Android 14. Steps to Reproduce: Start the app and enable the background geolocation watch. The background geolocation watch should reliably continue to function when the app is moved to the background. Actual Behavior: Most of the time, the background geolocation watch stops when the app is moved to the background. Log: Notes: This issue seems to be more prominent on devices running Android 14. |
|
Also found this log: 2024-07-23 09:11:58.373 1691-4305 ActivityManager system_server W Foreground service started from background can not have location/camera/microphone access: service **********/com.equimaps.capacitor_background_geolocation.BackgroundGeolocationService |
|
Background geolocations never arrive if the notification icon is misconfigured. In your log, you have the line |
|
We've noticed that when we add the ACCESS_BACKGROUND_LOCATION permission into our AndroidManifest.xml, the app settings show the "Allow all the time" option for location permissions. Selecting this option enables the app to function correctly in the background, consistently collecting location data and sending it to our server via the Capacitor.Http plugin. Given this setup, we are curious about the necessity of additional handling via local notifications or similar methods. Could you please provide some insights or clarification on why such additional handling might be required? Additionally, we would like to be able to select the "Allow all the time" option right at the beginning when the plugin prompts for location permissions. Our main goal is to track users on the map while they are using our app, and we do not want to require every single user to manually go to the app settings and enable this option. |
|
I've written a bit about the permissions model at #58 (comment). Have a read and let me know if it doesn't answer your question. |
|
Our application has a specific need for continuous background location tracking, and we have encountered some issues that we would like to clarify and seek your support on. Our Use Case: The Problem: Why We Need ACCESS_BACKGROUND_LOCATION: Dynamic Adjustment: We need to dynamically adjust the distanceFilter to handle different scenarios, such as precise locations when users are walking and broader distances when they are driving. This requires the ability to restart location watches in the background. If this plugin is not built for such use cases, please let us know. We would greatly appreciate any guidance or suggestions you can provide to help us achieve consistent background location tracking. If there are alternative approaches we should consider, please let us know. Thank you for your assistance. |
|
I see. You could try starting the new watcher before stopping the previous one, that should prevent the foreground service from stopping. The ACCESS_BACKGROUND_LOCATION permission seems too heavy handed for this plugin. Google are very stringent in their review of apps that list ACCESS_BACKGROUND_LOCATION in the manifest, because of the potential for abuse. I think you have already discovered that it is not possible to prompt the user for this permission. From what you are saying, however, the ACCESS_BACKGROUND_LOCATION makes it possible to start a foreground location service from the background. I know of one alternative, https://github.com/transistorsoft/capacitor-background-geolocation. It is not free, but it seems to do everything you could ever want. |
|
Thank you for your previous response. We have conducted further testing and have some additional observations and persistent issues to report: Logs and Observations App Foreground and Background Behavior: When the app is in the foreground, we can start and utilize the foreground service without issues. This is confirmed by the consistent location updates received while the app is active. Foreground Service Restriction: This restriction prevents the foreground service from accessing location, camera, or microphone data, aligning with Android's privacy policies. This inconsistency is causing interruptions in our app’s functionality when it is not in the foreground. Persistent Issues Despite starting a new watcher before stopping the previous one, the foreground service still faces restrictions when the app is backgrounded. This approach has not resolved the issue. The suggested use of ACCESS_BACKGROUND_LOCATION permission seems to address part of the problem. However, as you noted, Google’s stringent review process and potential for abuse make this permission less ideal for our use case. Logs:
|
|
We tested the app without the dynamic distanceFilter setup. We created the foreground service once and then toggled the app between foreground and background. However, the foreground service randomly stops. 2024-07-24 11:03:54.645 1691-6579 ActivityManager system_server W Foreground service started from background can not have location/camera/microphone access: service [APP_ID]/com.equimaps.capacitor_background_geolocation.BackgroundGeolocationService We toggled multiple times between foreground and background. Sometimes it worked, and we received tracking notifications when the foreground service was running in the background. However, other times, it did not work. The location icon disappeared from the phone's status bar, no notification was provided, and this log appeared: "Foreground service started from background cannot have location/camera/microphone access: service." The app is functioning correctly without any other errors or crashes. When you developed the plugin, did you test the notification delivery in scenarios where the app is toggled multiple times to ensure that the foreground service runs continuously without any issues? We are confused of this inconsistency. |
|
We've added a method to check the ACCESS_BACKGROUND_LOCATION permission in the BackgroundGeolocation plugin. This helps apps ensure they have the necessary permissions before accessing location services in the background, which is crucial for avoiding issues on Android 14. Could you please review and merge this pull request? It would greatly help us and other users of the plugin. |
|
Continuing this discussion in #119. |
|
I am using this plugin in my ionic angular application but, If I remove the lapp from my background it was not working. |
Describe the bug
Hi, I'm using the official @capacitor/geolocation plugin to get the current location, and this
@capacitor-community/background-geolocationplugin to get continuous location. The plugins were working completely fine side by side when using the 1.4.11 version. After updating this plugin and node modules of my project, app tends to crash the moment any function of @capacitor/geolocation is called. This only happens in Android 13+ devices.To Reproduce
Steps to reproduce the behavior:
Expected behavior
The app to work smoothly like it did before updating the package.
Smartphone (please complete the following information):
Additional context
I'm using an ionic 6.7.5 project with capacitor V4.
Any context on why this is happening would be nice. Thanks!
The text was updated successfully, but these errors were encountered: