I am studying Android driver/kernel. I find that there are 2 set of watchdogs:
kernel/watchdog.c
/drivers/watchdog/tegra_wdt.c
Both them are used to recovery the system as system hang on an event (e.g. infinite loop).
The first one is enabled in system boot time by default, but many people still implementing their watchdog in /drivers/watchdog/ folder for specific driver. I confuse about this. Why should we need multiple watchdog? Is any one know about the "philosophy" about this?
Because Watchdog is used for the secure thread, with the help of this we can stop the thread so it will not be able to perforrm any longer.
Related
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).
I have been developing for Android for little less then 2 years, and I am still puzzled by this seemingly simple question.
When should one implement a service?
From my experience there are some rare cases but I am questioning this because on every phone there are quite a lot of them running and I doubt it's just a poor application design.
This is essentially core of my question but following are some of my experiences and thoughts about the subject which can explain my question in more detail.
In all apps that I have developed only one really required a service. It was a background sound recorder and I was using it as Foreground service with notification since I wanted buttons to be able to control it (like music players do for example).
Except this I never really saw a requirement for the constantly running service because:
A) Intent listeners (Manifest registered BroadcastReceivers) are quite a useful feature and using them as you know is usually enough for many use-cases (for example showing notifications).
B) If scheduled execution is a must one can subscribe to alarm events.
C) I know that service in Android is quite different then for example in Windows since in Android services are just a "package" to organize your code in and have a the system manage the lifetime of the object. Services use the Main Thread but it's customary to spawn new threads in them.
D) In the development documentation services are suggested for network communication and background calculations but I don't get why you should not just use AsyncTasks for that. I am a big fan of these and use them extensively for lot of things from downloading data from the internet to doing FFT calculations under time critical conditions.
E) I get the usefulness of Foreground services but why are people using background services so much (excluding the system apps).
Those are my thoughts about the SERVICE and I hope someone with more experience will be able to explain these PROS and CONS (along with others that I probably missed).
When should one implement a service?
When you have work -- delivering value to the user -- that:
Needs some time to complete, perhaps longer than you have time for in the component wishing the work to be done, or
Is delivering that value under user control (e.g., music player, controlled by play/pause buttons in a UI), or
In rare cases, needs to be running continuously, as it delivers value continuously
there are quite a lot of them running and I doubt it's just a poor application design
Some are likely to be poor implementations, either due to technical misunderstandings, or other concerns (e.g., making marketing happy) trumping making users happy.
It was a background sound recorder and I was using it as Foreground service with notification since I wanted buttons to be able to control it (like music players do for example)
That is a reasonable use for a service, IMHO.
Intent listeners are quite a useful feature and using them as you know is usually enough for many use-cases (for example showing notifications)
I assume that by "Intent listeners" you mean manifest-registered BroadcastReceivers. In that case, if the work to be done by the BroadcastReceiver will take more than a millisecond, that work should be delegated to an IntentService for completion. onReceive() is called on the main application thread, and it is not safe for a manifest-registered BroadcastReceiver to fork a bare thread, as the process could go away shortly after onReceive() returns. However, in these cases, the service is usually short-lived (e.g., do some network I/O and disk I/O, then go away).
In the development documentation services are suggested for network communication and background calculations but I don't get why you should not just use AsyncTasks for that
An AsyncTask is a fine solution for background work that is:
Requested by the UI (activity or fragment), and
Will take less than a second or so, and
Is non-critical
For example, if you are downloading avatars to show in a ListView, AsyncTask is probably a fine choice, whether you use them directly or use some image-fetching library that uses them internally.
Conversely, if the user buys an MP3 through your app, and you need to download that MP3 file, an AsyncTask is not a good solution. That could easily take over a second. While the download is going on, the user could switch away from the app (e.g., press HOME). At that point, your process is eligible to be terminated... perhaps before your download is complete. Using an IntentService to manage the download is a signal to the OS that you are really doing work here, adding value to the user, and so the process will be left alone for a little while.
Note that if the background work might take 15+ seconds, WakefulBroadcastReceiver or my WakefulIntentService is probably a good idea, so the device does not fall asleep while you are trying to wrap up this bit of work.
I can name some of the Service uses from my experience:
to implement
location listener,
sound module, generating various voices
in app content updates,
API, provide services to other apps
in app billing
Communication with webservices (if requests frequency is high)
actually (excluding 5.) they all are working for the whole app duration, they are using some of the other android services, also they manage their state. I suppose one of the important thing here is state management during application life cycle changes.
I prefer to look at AsyncTasks in a same way as Executors (ExecutorService), they should be executed sequentially and for small tasks.
In the android website, you can find a table when to use Service, Thread, or WorkManager (the new API for scheduling jobs, currently in alpha as of this comment posted). https://developer.android.com/guide/background/#table-choose
The website also state that you need to use started service only as last resort. The Android platform may not support started services in the future. Refer to this link https://developer.android.com/topic/performance/scheduling#services
You should avoid using started services that run perpetually or perform periodic work, since they continue to use device resources even when they aren't performing useful tasks. Instead, you should use other solutions that this page describes, and that provide native lifecycle management. Use started services only as a last resort. The Android platform may not support started services in the future.
If you consider UI and bound services, u would think that both can exist and not be doing anything for certian periods. In such scenarios, your UI can be recreated a lot of times however service does not. And this is where service is important. Lets say you are processing images and then rotate device you want processing to continue while UI is being recreated. You recording a voice and then rotate device. These are one of the places where I find service very important. (Having lot of heavy data processing, interaction with web, that could be few seconds)
I am new to android dev. Our requirement is to run a background service in android. Which is unkillable or it is capable to handle KILL signal from taskmanager..
Is there is any way to do it?
I have heard about addShutdownHandler, But it wont fired when user kills it.
Thanks in advance
Is there is any way to do it?
Only by building your own custom version of Android, with your code in a standard C/C++ daemon, and then distributing a ROM mod that contains that customized version of Android.
If you are trying to create an ordinary SDK app, the user or Android itself can get rid of your process at any time, for any reason.
In general: not possible.
I should add that trying to impose such a requirement makes you sound nefarious -- there's a reason the user is allowed to kill processes.
From man 7 signal:
The signals SIGKILL and SIGSTOP cannot be caught, blocked, or ignored.
This is fundamentally by kernel design. Think about it: if a process could ignore all signals whatsoever, then how would you stop it if it ran away uncontrolled? No, what you'll have to do is see to it that the KILL signal is not sent. Running your program under its own userid should achieve this, as long as no one with administrative privileges generates the signal -- but even this requirement may be practically impossible to meet. By design, the system provides the basic ability to kill a process, on the theory that the user or sysadmin might (for whatever reason) want the process killed.
Is there any possibility to create a listener for closing another process?
Let's say I want to know when the process com.android.test.app isn't running anymore.
By the way, I don't want to use threads for listening for current running apps.
Btw I don't want to use threads for listening for current running apps.
From what I know, there is no other way supported by Android as yet.
I'd like to point out that getRunningAppProcesses() checking processes with IMPORTANCE_EMPTY or IMPORTANCE_BACKGROUND is one of doing this but as per the documentation :
Note: this method is only intended for debugging or building a user-facing process management UI.
I'm trying to make a stopwatch & countdown app for WindowPhone 7 using Silverlight for WindowPhone SDK and trying to make it run in background when it's tombstoned. In Android, I can use android.app.Service to run it in background. According to MS AppHub Quickstart, "The Windows Phone operating system doesn't allow any third-party applications to run in the background". Please help me if you have any idea for keeping the countdown running when a phone call is received or the phone goes to sleep. Thank you.
At the moment, once your app is tombstoned, your app cannot continue with any custom processes such as having your countdown continue. The Mango SDK coming out this month allows for a bit more freedom in this respect.
If, however, you want to run your app under a lock screen, this is possible. You can simply do this:
PhoneApplicationService.Current.ApplicationIdleDetectionMode = IdleDetectionMode.Disabled;
Jaime Rodriguez has a great post on running under a lock screen which you can read here.
Until Mango comes out, there's no way to have your program run in the background.
As keyboardP notes, you can't continue your process on the phone.
However you could use a server and Toast message popups to still notify the user. It requires more setup and a server to run against, but it will meet your requirements.
One thing I have seen with other people making apps like this is to store the time that app was tombstoned and then, when the app is reactivated to look at the difference between the current time and the saved time and deduct that from the countdown.
This may or may not be appropriate, depending on your requirements but may be something to consider.