Is there a way to know which process my code is running on?
My app has two processes, one is the main process, the other process is used by an external SDK.
My custom application object is sometimes called from the other process.
I want to know which process is calling the application object.
Is it possible?
Related
I am using the WorkManager API that is supposed to be able to run even while the app isn't started or is killed(?) Then I wonder, if app isn't started or is killed, which process does the work actually execute in? Some system process? Or is it actually (by default) always running in a designated thread in the app process if nothing else is specified? I am confused. If it is running in the app process, does it start the app process without actually starting anything else in it, then?
I am curious to whether I can access my app's data from within the work while it is executing. I mean I am not supposed to be able to access for instance a singleton app member in case it is running in a completely separate process.
I'm writing a service for an Android application component and I want my App to not crash because of any fault in service. By default Is the app is protected from any faulty behavior of background service.
To answer your question, Yes. Your application will be terminated if a service within your application crashes. To provide a solution, don't let the service crash. I believe you can prevent a service from crashing if you can prevent whole rest of application. Use try-catch or other programming approaches to handle exceptions. Let us know if anything specific in code needs help for those purposes.
Update: I was assuming you are using "single process model".
As the comment suggests, there is more to it. Your process will be terminated if a service within that process crashes. Your application will be terminated if the main thread is running under same process.
By default, Android uses same process throughout your application. In that case, the application will be terminated if any exception occurs (because the process is crashed). You can specify different processes to be run for different activities under manifest (if you "really" need it).
See Process and thread for more details on how to do it.
One option is to run your Service in a separate process from the rest of your app. If your Service crashes, this will not directly crash your app (ie: your activities). However, you then need to figure out how your app should continue to operate once the Service has crashed. Of course, your app can attempt to restart the Service and/or take other measures.
To do this, just add this to the <service> declaration in your manifest:
android:process=":remote"
I want to know what is the difference between a process and a service in an android app?
I tried to study about this topic a lot, but did not clear my basics yet...please help?
A process and a service are two different things:
What is a Service?
Most confusion about the Service class actually revolves around what it is not:
A Service is not a separate process. The Service object itself does not imply it is running in its own process; unless otherwise specified, it runs in the same process as the application it is part of.
A Service is not a thread. It is not a means itself to do work off of the main thread (to avoid Application Not Responding errors).
Thus a Service itself is actually very simple, providing two main features:
A facility for the application to tell the system about something it wants to be doing in the background (even when the user is not directly interacting with the application). This corresponds to calls to Context.startService(), which ask the system to schedule work for the service, to be run until the service or someone else explicitly stop it.
A facility for an application to expose some of its functionality to other applications. This corresponds to calls to Context.bindService(), which allows a long-standing connection to be made to the service in order to interact with it.
source: http://developer.android.com/reference/android/app/Service.html
What is a Process
When an application component starts and the application does not have any other components running, the Android system starts a new Linux process for the application with a single thread of execution. By default, all components of the same application run in the same process and thread (called the "main" thread). If an application component starts and there already exists a process for that application (because another component from the application exists), then the component is started within that process and uses the same thread of execution. However, you can arrange for different components in your application to run in separate processes, and you can create additional threads for any process.
source: http://developer.android.com/guide/components/processes-and-threads.html#Processes
In the app I'm developing atm. I use asynctasks to upload videos to a website, as it stands now if the application process is killed (User returning to home screen using the back key), those asynctasks are lost. ideally I would want the uploads to carry on despite the application process being killed, but I don't think that is possible.
I wonder if there is a way to retain their progress somehow (Maybe support from the website API is necessary?), or if not at least save the details of the asynctask and restart it when the app is opened again.
Vimeos application seems to have been able to resume video uploads, even after having killed the application process, thats exactly what I'm hoping to achieve.
Appreciate any ideas and suggestions.
I think you may be using the wrong architecture.
Anything that needs to survive in between Activity transitions is more suited for a Service. A service runs in the background (possibly even after the app is closed) and lets you do long running things such as performing uploads.
To kill the app process but have the Service continue to run, you can assign the service to a separate Android process using android:process in the manifest.
http://developer.android.com/guide/topics/manifest/service-element.html#proc
See this thread too:
How to keep a service running in background even after user quits the app?
What are the practical differences between putting a service in a separate process or keeping it in the app's main process? What would each scenario be used for?
When a service is running in the main process it will be stopped in case your application crashes for whatever reason. Put a service into it's own process is reasonable for some services which can be used from different applications or services which should run independently from your main app.
The only reasons I see for putting a service in another process is
The application is resource heavy and likely going to be killed quickly by the OS. Putting the service in a separate process will distribute the resources and if you application dies your service won't.
JUST in case your application has errors and dies your service will keep going.
However if you create a good application and use good programming you should not run into either of these issues. By having your service in a separate process it causes trouble with things like SharedPreferences and concurrent DB access... I would recommend not doing it.
Not to mention... another process means another DVM. This will take more resources than running in one DVM and slow things down.
Also putting service in another process makes your changes of static variables invisible for main process. You can get situation, when you assign a variable with some value, and it is not changed!! I spent whole day for this issue!
Following is a quote from Android Developer's web site.
Note that services, like other application objects, run in the main thread of their hosting process. This means that, if your service is going to do any CPU intensive (such as MP3 playback) or blocking (such as networking) operations, it should spawn its own thread in which to do that work.
Jake points out that you can, thru manifest, control the Name of the process it is running. But following findings from Documentatioin:
Most confusion about the Service class actually revolves around what it is not:
A Service is not a separate process. The Service object itself does not imply it is running in its own process; unless otherwise specified, it runs in the same process as the application it is part of.
This is interesting, what is said Here is:
The name of the process where the service is to run. Normally, all components of an application run in the default process created for the application. It has the same name as the application package. The element's process attribute can set a different default for all components. But component can override the default with its own process attribute, allowing you to spread your application across multiple processes.
But anyway, if you need Service to be exposed to other applications, for example, you need to provide content (like phonebook) to other applications, setting service to run in different process is the reason.
Using the process attribute of a service is rejected by the manifest parser so it is rather misleading!