I'm trying to create an app that manages a BLE connection in the background (receives notifications, reconnects and subscribes to a characteristic when connection is lost and the phone is moved near the BLE device again).
Right now I have the app somewhat built - everything that I need works relatively well but only when the app is open. Although the code isn't up to standard as this is my first app and I don't have any previous experience with Java/Kotlin/Dart (this is also why I'd rather not touch anything outside of flutter).
I need the app to send me local push notifications when tabbed out of the app or when screen lock is on and as far as I understand one could do this with isolates. I've searched a lot but found one guide which is kind of hard to understand as a beginner and also uses Kotlin.
Can I get away with only dart code for background code execution (described above) and is it suitable for a beginner?
Also, let me know if you have any alternative solutions since all I need is to get a notification on my phone whenever it receives a notification from a BLE device (and also auto connecting). I've already tried this with kivy since I'm more familiar with python but with no luck.
Talking about BLE there's this plugin by the way: https://pub.dev/packages/flutter_reactive_ble
As for the isolates, they are not ideal for this even though they do run separately, they'll get killed eventually. There's also a little helper package that makes working with isolates very straightforward if you want to try it: https://pub.dev/packages/computer
And so actually for the task at hand (background execution) I would suggest researching/using this one: https://pub.dev/packages/background_fetch
I would not encourage you to use any timer-based solution that tries to wake up your phone every 15 minutes or so, since that uses unnecessary CPU time.
Now I'm not that much into Flutter, but at least on Android, the "correct" way to have an ongoing connection (auto-connect) is to have a Foreground Service in the process running, so the process does not get killed. Then subscribe to characteristic notifications as usual, and handle the values as they arrive, either in Java or Flutter (by using some Java <-> Dart bridge).
For some strange reason, which I'm not entirely sure why, I'm getting not only an ANR for my application, but also of the entire systemui. It's so bad that I HAVE to reboot, and after rebooting it has to "Optimize" all of my apps like it corrupted something (anyone have an explanation as to why this happens?).
I'm assuming that parts of my code are so bad that they're causing this, but should even malicious code be able to overload the systemui? Anyway...
What I am doing is that I'm attempting to launch a service to handle screen recording. The activity (from a fragment) asks for permission (which is obtained, and I see the Screencast icon in the top right corner of the screen), then it binds a service which handles any state changes. What I mean by state changes is this...
States:
Dead - Means it needs to be initialized and prepared
Alive - Means it needs to be start and is fully initialized/prepared
Started - Means it is currently recording.
Paused - Means it will start a new video after starting again, which it will combine all temporary videos into one (haven't worked out that details yet).
Stopped - Means combine any and all files into one, then send the URI through an intent in a broadcast (haven't gotten this far yet).
It goes from Dead -> Alive -> Started <-> Paused -> Stopped -> Dead. At least that's the overall plan. I plan on having a floating button that acts as remote for controlling the service, and hence broadcasting on a receiver (local) to my fragment which is waiting for it to be finished.
Now, enough of what I intend to have, lets get into what I have right now. It's kind of a mess, I've never done this stuff before, hence why I'm asking on here. Trust me when I say that I have tried a lot of stuff, and the unfortunate bit is, the only way to test out a new solution is to reboot and wait 15 minutes while Android optimizes everything again. Now I understand it's a "Long" code-segment, but I'll say that one place it crashes is stopRecording(), at line 216.
Code here.
Let me know if I should make any changes.
Lastly: Should any of this be run on another thread? Could that be the issue? Why doesn't the app crash only instead of systemui?
I'm developing an application in cordova/phonegap and it is about tracking a person his gps location and therefore the app needs to be active for a long time
I can keep the application active as long as it is in memory but when you have opened so many applications that android needs more ram space it still kills the application
I know services exist in android but I just cant tell how to use them in combination with a phonegap app
Is there a way to keep the activity of my app in front of the activity stack so it doesnt get killed or can i write a native service that restarts my application when it gets killed (with thesame state as it got when it got killed)
More detailed description of the problem
ok as requested a more detailed description of the problem
I have a cordova application (html + javascripts)
in a the application i use navigator.watchposition() which gets called when the gps location changes
i then do some logic and store the data in a websql database (on the device itself), as far as i know this database is only accesible from within a webview
now the point of this application is that it you start it at the morning and stop it in the evening (for example lets say say active for 10 hours from start to finish) you dont need to see the application, and the screen doesnt need to be on
I got the stay active part working for when android never ran out of memory
So what I need to do to get to my problem is start the application -> press the home button -> start about 10 different application (to simulate normal use of a phone), the number 10 can vary on different phones with different ram sizes -> after opening enough other applications my phone will run out of ram memory so then android kills some apps and eventually will kill my app.
This is not good for our application at it tracks time at a location and needs to do this fairly accurately
-------
anyway thanks in advance for your help
You should not try to do that. It's against the principles of Android. Instead you should, as you already suggested yourself, use a service to track the GPS location.
I have met the same problem.
In android, activity life cycle can only changed by system, when the activity not on the top, it will easy to be killed by system, so next time you come into your app , it will start from onCreate function on main.java.
If you want make something work background , use service will more appropriate.
I recently began writing a phonegap android application and noticed that when the app is resumed from the background (so I deploy the app to an android tablet, press the home button and then reopen the app from the menu) it gives a timeout error (something to the effect of Error code =-6 The connection to the server was unsuccessful) and then crashes. From what I've tested this only seems to happen when the "Don't keep activities" option is checked in the developer options, when that option is not checked the app works as intended.
It's also worth noting that I recreated the default phonegap application, ran it and encountered the same issue.
Can anyone explain why this happens, or suggest a solution? Obviously I can get around this problem by simply leaving the Don't keep activities option unchecked, but I'm guessing the problem will persist on any android device that has this option checked, which just won't do.
I'm using phonegap 2.5.0 and testing on a device running Android 4.0.3,
Thanks,
Josh
"Don't keep activities" is a developer tool to simulate user activity that would be extremely hard to test for. I personally believe all apps should be tested a second time (at least run automated tests) with this setting turned on, and devs should turn it on / off during development.
Your issue (which I've just ran into on v2.7) comes from a silly implementation of a timeout feature. CordovaWebView.loadUrlIntoView creates and locks (wait()) a thread for 20 seconds (default value), after which time it checks a value to see if the url finished loading - if it hasn't finished, it shows an error message.
This thread exists outside of the lifetime of your activity, so if the activity stops running, the Webview can never finish loading the url, and when the thread wakes up, it does Bad Things trying to show the error.
The same crash could happen without using "Don't keep activities" by simply having the user leave the application and then the system reclaiming the activity's resources (because it is low on memory or something) within 20 seconds.
Using a Handler seems like a more appropriate way to handle this timeout, but without changing the source there are a couple of hacky work arounds.
Call System.exit(0) at the end of your Activity.onDestroy() - this is horrible, but if you only have the one activity and no services, it might be an option
Use reflection to change CordovaWebView.loadUrlTimeout - this is horrible, but it should work, this is the value that the thread checks to see if the url loaded (inc by 1).
This question already has answers here:
Is quitting an application frowned upon?
(40 answers)
Closed 9 years ago.
Please suggest how I may close my whole Android Application with one line code.
Yes - Why, then how(sort of):
Short answer:
System.exit(0);
This nicely and cleanly terminates the whole java machine which is dedicated to running the app. However, you should do it from the main activity, otherwise android may restart your app automatically. (Tested this on Android 7.0)
Details and explanation of why this is a good question and a programmer may have a very legitimate reason to terminate their app this way:
I really don't see the gain in speaking harshly to someone who's looking for a way to terminate their app.
Good is a friendly reminder to beginners that on Android you don't have to worry about closing your app -- but some people actually do want to terminate their app even though they know that they don't have to -- and their question of how to do so is a legitimate question with a valid answer.
Perhaps many folks live in an ideal world and don't realize that there's a real world where real people are trying to solve real problems.
The fact is that even with android, it is still a computer and that computer is still running code, and that it is perfectly understandable why someone may wish to truly exit their "app" (i.e. all of the activities and resources belonging to their app.)
It is true that the developers at Google designed a system where they believed nobody would ever need to exit their app. And maybe 99% of the time they are right!
But one of the amazing things about allowing millions of programmers to write code for a platform is that some of them will try to push the platform to its limits in order to do amazing things! -- Including things that the Android Developers never even dreamed of!
There is another need for being able to close a program, and that is for troubleshooting purposes. That is what brought me to this thread: I'm just learning how to utilize the audio input feature to do realtime DSP.
Now don't forget that I said the following: I well know that when I have everything done right, I won't need to kill my app to reset the audio interface.
BUT: Remember, perfect apps don't start out as perfect apps! They start out as just barely working apps and grow to become proper ideal apps.
So what I found was that my little audio oscilloscope test app worked great until I pressed the android Home button. When I then re-launched my oscilloscope app, there was no audio coming in anymore.
At first I would go into
Settings->Applications->Manage Applications->AppName->Force Stop.
(Note that if the actual linux process is not running, the Force Stop button will be disabled. If the button is enabled, then the Linux process is still running!)
Then I could re-launch my app and it worked again.
At first, I was just using divide by zero to crash it - and that worked great.
But I decided to look for a better way - which landed me here!
So here's the ways I tried and what I found out:
Background:
Android runs on Linux.
Linux has processes and process IDs (PIDs) just like Windows does, only better.
To see what processes are running on your android (with it connected into the USB and everything) run adb shell top and you will get an updating list of all the processes running in the linux under the android.
If you have linux on your PC as well, you can type
adb shell top | egrep -i '(User|PID|MyFirstApp)' --line-buffered
to get just the results for your app named MyFirstApp. You can see how many Linux Processes are running under that name and how much of the cpu power they are consuming.
(Like the task manager / process list in Windows)
Or if you want to see just the running apps:
adb shell top | egrep -i '(User|PID|app_)' --line-buffered
You can also kill any app on your device by running
adb shell kill 12345
where 12345 is it's PID number.
From what I can tell, each single-threaded app just uses a single Linux process.
So what I found out was that (of course) if I just activate the android Home option, my app continues to run.
And if I use the Activity.finish(), it still leaves the process running.
Divide by zero definitely terminates the linux process that is running.
Killing the PID from within the app seems the nicest so far that I've found, at least for debugging purposes.
I initially solved my need to kill my app by adding a button that would cause a divide by zero, like this in my MainActivity.java:
public void exit(View view)
{
int x;
x=1/0;
}
Then in my layout XML file section for that button I just set the android:onClick="exit".
Of course divide by zero is messy because it always displays the "This application stopped..." or whatever.
So then I tried the finish, like this:
public void exit(View view)
{
finish();
}
And that made the app disappear from the screen but it was still running in the background.
Then I tried:
public void exit(View view)
{
android.os.Process.killProcess(android.os.Process.myPid());
}
So far, this is the best solution I've tried.
UPDATE: This is the same as above in that it instantly terminates the Linux process and all threads for the app:
public void exit(View view)
{
System.exit(0);
}
It instantly does a nice full exit of the thread in question without telling the user that the app crashed.
All memory used by the app will be freed. (Note: Actually, you can set parameters in your manifest file to cause different threads to run in different Linux processes, so it gets more complicated then.)
At least for quick and dirty testing, if you absolutely need to know that the thread is actually fully exited, the kill process does it nicely. However, if you are running multiple threads you may have to kill each of those, probably from within each thread.
EDIT: Here is a great link to read on the topic:
http://developer.android.com/guide/components/fundamentals.html
It explains how each app runs in its own virtual machine, and each virtual machine runs under its own user ID.
Here's another great link that explains how (unless specified otherwise in manifest) an app and all of its threads runs in a single Linux process: http://developer.android.com/guide/components/processes-and-threads.html
So as a general rule, an app really is a program running on the computer and the app really can be fully killed, removing all resources from memory instantly.
(By instantly I mean ASAP -- not later whenever the ram is needed.)
PS: Ever wonder why you go to answer your android phone or launch your favorite app and it freezes for a second? Ever reboot because you get tired of it? That's probably because of all the apps you ran in the last week and thought you quit but are still hanging around using memory. Phone kills them when it needs more memory, causing a delay before whatever action you wanted to do!
Update for Android 4/Gingerbread: Same thing as above applies, except even when an app exits or crashes and its whole java virtual machine process dies, it still shows up as running in the app manager, and you still have the "force close" option or whatever it is. 4.0 must have an independent list of apps it thinks is running rather than actually checking to see if an app is really even running.
You could finish your Activity by calling Activity.finish(). However take care of the Android Activity life-cycle.
You could close your Android Application by calling System.exit(0).
just call the finish() in the method you would like to end the activity in, for example when you use the onCreate() method, in the end of the method, just add finish() and you will see the activity ends as soon as it is created!
As per my knowledge, finish function close the current displayed screen only.
Refer this example (where see the answer given by 'plusminus'), it will sure help you to close your application.
Before doing so please read this other question too:
android.os.Process.killProcess(android.os.Process.myPid());
android.os.Process.killProcess(android.os.Process.myPid());
This code kill the process from OS
Using this code disturb the OS. So I would recommend you to use the below code
this.finish();
Intent intent = new Intent(Intent.ACTION_MAIN);
intent.addCategory(Intent.CATEGORY_HOME);
intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
startActivity(intent);
The answer depends on what you mean by "close app". In android's terms its either about an "activity", or a group of activities in a temporal/ancestral order called "task".
End activity: just call finish()
End task:
clear activity task-stack
navigate to root activity
then call finish on it.
This will end the entire "task"
not a one-line-code solution, but pretty easy:
sub-class Activity, then override and add finish() to onPause() method
this way, activity will be gone once it enters background, therefore the app won't keep a stack of activities, you can finish() the current activity and the app is gone!
If you close the main Activity using Activity.finish(), I think it will close all the activities.
MAybe you can override the default function, and implement it in a static way, I'm not sure
I don't think you can do it in one line of code. Try opening your activities with startActivityForResult. As the result you can pass something like a CLOSE_FLAG, which will inform your parent activity that its child activity has finished.
That said, you should probably read this answer.
That's one of most useless desires of beginner Android developers, and unfortunately it seems to be very popular. How do you define "close" an Android application? Hide it's user interface? Interrupt background work? Stop handling broadcasts?
Android applications are a set of modules, bundled in an .apk and exposed to the system trough AndroidManifest.xml. Activities can be arranged and re-arranged trough different task stacks, and finish()-ing or any other navigating away from a single Activity may mean totally different things in different situations. Single application can run inside multiple processes, so killing one process doesn't necessary mean there will be no application code left running. And finally, BroadcastReceivers can be called by the system any time, recreating the needed processes if they are not running.
The main thing is that you don't need to stop/kill/close/whatever your app trough a single line of code. Doing so is an indication you missed some important point in Android development. If for some bizarre reason you have to do it, you need to finish() all Activities, stop all Services and disable all BroadcastReceivers declared in AndroidManifest.xml. That's not a single line of code, and maybe launching the Activity that uninstalls your own application will do the job better.