Android Process Scheduling

What does application's own process mean in android Job Scheduler

A process is a technical term in the realm of Operating Systems. A process is basically 1 or more threads of execution that share resources and memory. Basically a single instance of an application being run. A new thread is not a new process, but running another application would be, or running a second instance of the same application.

In general in Android an app is a single process. There are ways to launch services in separate processes, but its a very niche thing to do with limited reasons to do so.

What that does mean is that JobScheduler runs the job in the same process as the app- if the app is already running, it won't start a new instance of the app, it will run it on the existing resource. That means they can share memory and other resources with any activities or services currently running.

OS ( Specifically Android's ) Process

For background information, I'd recommend reading Wikipedia's articles on Process (computing) and Thread (computer science). Also possibly useful (though slightly dated now) is the chapter on process scheduling from Understanding the Linux Kernel.

For an Android-specific answer, there is a previous question on Android Process Scheduling that has several answers.

On Android, are cached processes still scheduled on the CPU?

Specifically, are cached processes no longer scheduled on the CPU?

I don't usually think of processes being scheduled on a CPU. I think of threads as being scheduled on a CPU. Perhaps we are just using the terms differently.

A cached process' threads are no different than any other process' threads. Ideally, a cached process only has threads that are blocked waiting on something (e.g., IPC from a core OS process, telling the app process to start another activity in response to the user pressing a icon from the home screen). However, there is nothing stopping an app from having leaked some thread that continues running, for however long that process remains cached.

For example, you could create an app with a single activity like this:

class MainActivity : AppCompatActivity() {
  override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContentView(R.layout.activity_main)

    Executors
        .newSingleThreadScheduledExecutor()
        .scheduleAtFixedRate({ Log.e("BadWolves", "Zombie!") }, 5, 5, TimeUnit.SECONDS)

    finish()
  }
}

Here, I fork a zombie thread, then finish() the activity. The process moves into the cached state fairly quickly, once the activity is destroyed. Yet, the zombie thread continues logging to LogCat.

How long it logs to LogCat varies by OS version and perhaps manufacturer tweaks. So, for example, on the Pixel 2 that I just tossed this onto, it has been logging for 10 minutes, which frankly is longer than I would have expected on Android 8.1.

This would mean that it was the duty of every app in existence to implement pausing correctly when backgrounded.

Yes, to an extent. The OS can terminate your process at any point, and cached processes are prime candidates to be terminated when system RAM is needed. So, leaked threads usually don't live all that long, because cached processes usually don't live all that long. Part of the reason why my zombie is staggering around as long as it is is that this device isn't used for a lot, so I don't have a lot of processes coming and going, minimizing pressure on system RAM.

_{Now, if you'll excuse me, I need to kill a zombie...}

How to modify android kernel process scheduler?

To modify the Android's kernel scheduling policy is unlikely to be allowed from a security point of view. But based various features of "realtime" you can always make your program meets these requirements:

a. Responsiveness: by ensure the input loop is as efficient as possible and always responding as fast to input as possible. In the Linux kernel this is done through "voluntary preemption".

b. Low latency: by piecing every jobs into as small a piece as possible so that control can be passed back to respond to input, or in the case of audio, control can be issued at a precise start of the clock (SCHED_DEADLINE scheduling). Android does have some API for this:

http://source.android.com/devices/audio/latency_design.html

In general changing priority is not ideal to solve the realtime requirement (eg, giving higher priority to one process may end up having another process suffering in performance). What is actually done (eg, LynxOS, a realtime OS used in Missile system, and is not Linux, but some of its component like TCP/IP is from FreeBSD) is to tune the system so that it perform at the level with lots of spare hardware capacity. So in LynxOS a lot of the system threshold limits are very low, so the hardware is always free enough to respond quickly to input events.

https://github.com/keesj/gomo/wiki/AndroidScheduling

Android Low latency Audio using SoundPool

Low-latency audio playback on Android

---

Related Topics