-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Android 9.0 stopOnTerminate:true requires two stops before app is terminated. #147
Comments
No logs? |
I highly recommend against using NativeScript. I’m going to stop selling licenses for it and cease support. I do highly recommend Flutter! |
From Google Trends' perspective:
These trends correspond with my sales & traffic stats year-over-year:
React Native vs Ionic vs Flutter vs NativeScript vs Xamarin I've made more sales for Flutter in 3 months (released just last October) than NativeScript in 2 years (released in 2016)! |
I am working on getting you the logs. I am unfamiliar with Flutter. Is there a migration path for a Typescript/Angular app to Flutter? Initial searches seem to indicate Dart is the only language supported. What makes Flutter a better platform than NativeScript or better yet, what are the problems with NativeScript? From what I've experienced, NativeScript is much better than Ionic/Cordova at least for the kind of long running app I am trying to build. I had to migrate from Cordova/Ionic to NativeScript. My codebase is getting significant and relies heavily on your plugin. My plan was to get a bit closer to launch and purchase a license. If you cease support for the plugin it is going to significantly set back my development. When do you plan to cease availability of the plugin? Other than purchasing a license, is there something I can do to keep access to the plugin? Would a very restricted (use on in my apps) source code license be possible to purchase? Failing that, could I pay you to keep supporting it in some capacity? |
How do you prefer the logs provided to you? adb logcat is very verbose and I'm not sure what you would like to see. |
I just noticed the debugging instructions. Sorry about not noticing that. I turned on verbose log messages. I started the app, started tracking, killed the app, and restarted it, confirming that it was not correctly killed, then killed it and restarted it again. The behavior is different today in that even when I relaunch the app a third time it appears to show up with state from the previous run. I also notice that it only appears listed in the Services list for a few seconds after I terminate it. If I force stop it from developer options and then restart it, the app starts up cleanly. I have worked around the issue by detecting whether or not there is an existing database connection, etc when the app fires up and it seems to work but this "app state persisting" seems to be a bug to me. Here's the output of: adb logcat -s TSLocationManager first start of app 04-16 19:06:34.053 8197 8197 I TSLocationManager: starting tracking 04-16 19:06:55.258 8197 8197 D TSLocationManager: [c.t.locationmanager.util.b a] killing the app 04-16 19:07:27.123 8197 8344 D TSLocationManager: [c.t.l.BackgroundGeolocationService onActivityRecognitionResult] still (100%) restarting the app 04-16 19:08:00.717 8197 8197 D TSLocationManager: [c.t.l.adapter.TSConfig c] ℹ️ Persist config killing the app again 04-16 19:08:23.919 8197 8347 D TSLocationManager: [c.t.l.BackgroundGeolocationService onActivityRecognitionResult] still (100%) restarting the app again 04-16 19:08:59.047 8197 8197 D TSLocationManager: [c.t.l.adapter.TSConfig c] ℹ️ Persist config |
Your Environment
tns info
):✔ Getting NativeScript components versions information...
⚠ Update available for component nativescript. Your current version is 5.3.1 and the latest available version is 5.3.2.
✔ Component tns-core-modules has 5.3.1 version and is up to date.
✔ Component tns-android has 5.3.1 version and is up to date.
⚠ Update available for component tns-ios. Your current version is 5.1.0 and the latest available version is 5.3.1.
Expected Behavior
Same behavior as in Android 8, namely that the app quits completely.
Actual Behavior
If I open the app and do not start geolocation and kill the app by swiping up, it is properly killed and I can restart it and get the expected behavior.
If I open the app, start geolocation, and then swipe the app up, it goes into what appears to be a partially killed state. The app is still listed for a short time in the System -> Developer -> Running Services list but if I then start the app again by tapping the app icon, I continue to get debugging messages from the previous instance and it comes up in an inconsistent state. (firebase complains about being initialized as does sqlite)
If I then swipe the app away again, it properly terminates. I no longer get any debugging messages and if I then tap on the app icon if fires up a fresh instance that works as expected. (firebase and sqlite don't complain about existing connections)
If I set "stopOnTerminate: false", then the app never disappears from the Running Services list no matter how many times I swipe it away. (As I suspect is the intended behavior.)
Under Android 8, even with stopOnTerminate: false and foregroundService: true, the app is properly killed.
Steps to Reproduce
Context
I suspect there is something about Android I do not understand. (This goes back to a documentation issue I filed with the cordova background geolocation project).
My suspicion is that this is probably an Android 9.0 bug or some change I'm unaware of since it works just fine under Android 8.
Debug logs
The text was updated successfully, but these errors were encountered: