I want to implement a service which should be running like standard system service on boot up, this service should not be kill-able and should be able to perform action on receiving notification from another process.
Can anyone help me which is the best methodology (AIDL) to create such service,if any example for reference ?
You can't do this unless you are creating your own system ROM.
If creating your own ROM, you can start by modifying the AndroidManifest of the apk containing your service. You need to add an attribute to your manifest node: android:sharedUserId="android.uid.system". That will cause your APK to hold the system ID (which requires the APK to be signed with your platform signing key -- this is why you need to be creating your own system ROM.
That will allow your application to be considered special by the system, and (at least on 4.x, I haven't tested on older Android versions) your application will be auto-started. The application being auto-started doesn't mean much on its own though; either you need to implement a BOOT_COMPLETED receiver as #febinkk suggests, or you can provide a custom Application override (by adding the attribute android:name="your.package.ApplicationSuperClass" to your application node in your AndroidManifest.xml). In your application super class, you can overload onCreate() and have it start your service or whatever else is required.
Additionally, as a system application, I believe (though have not fully tested) you will not be able to be killed through normal means.
You are not able to create non-killable, immune service without creating your own ROM
You could register a BroadcastReciever with filter for android.intent.action.BOOT_COMPLETED for your service and after starting call startForeground(). This may not be what exactly you were looking, but this is probably the only thing that comes near, if you don't want to create ROM.
Related
In Android it is possible to create a Service to do background tasks, etc by creating a subclass of Service. It order to use the Service it must be specified in the manifest for the app:
All services must be represented by elements in the manifest file. Any that are not declared there will not be seen by the system and will never be run.
One of the parameters for a Service in the manifest is the 'enabled' option:
Whether or not the service can be instantiated by the system — "true" if it can be, and "false" if not.
What is the purpose in declaring a Service to be disabled - if I didn't want the Service surely I just wouldn't write it / add it to the manifest in the first place?
The only use I can see for disabling a Service in the manifest, and it seems of limited value, is if it's a Service used only for debugging, and I want it disabled for production. Am I missing something?
The android:enabled attribute set to a boolean value defined in a resource file. The purpose of this attribute is to enable or disable the service on devices running on different Android OS version.
For example, to disable the service on devices running Android 4.3 or lower include menifest attribute android:enabled="#bool/atLeastKitKat".
In addition to including this attribute in the manifest, you need to do the following:
In your bool.xml resources file under res/values/, add this line:
<bool name="atLeastKitKat">false</bool>
In your bool.xml resources file under res/values-v19/, add this line:
<bool name="atLeastKitKat">true</bool>
if I didn't want the Service surely I just wouldn't write it / add it to the manifest in the first place?
In the very specific case of a Service, I agree that it would be rare for you to want to disable it. One possibility would be for a service that plugs into the system (e.g., input method editor, accessibility service) that you only want to enable at runtime (via PackageManager and setComponentEnabledSetting()) if the user make an in-app purchase that unlocks the feature. I am sure that there are other Service scenarios for this, though none are leaping to mind at this early hour of the day (yawn!).
However, I suspect that Service "inherits" its android:enabled setting by virtue of being one of the Android component types, along with activities, providers, and receivers. Other scenarios for android:enabled will be a bit more common with other component types. For example, it is considered good form to have your BOOT_COMPLETED receiver be disabled until you know that you need it. So, for example, if the BOOT_COMPLETED receiver is only used to resume a download interrupted by a reboot, you only need that receiver enabled if you are doing a download. At all other times, you may as well leave it disabled, so you don't waste the user's time during "normal" reboots.
I'm looking to expand my app to handle Guest Mode, introduced in Android L. I found that if I create a service with android:singleUser in AndroidManifest, with permission INTERACT_ACROSS_USERS, and I'm a system app by installing it in /system/priv-app, then my service is running even as I switch user. But my app needs to interact with the user, by being able to launch an activity, show a toast or notification. All of those things seems to not be possible. Is there a particular flag I need to set when I call startActivity so that it will launch a new activity from my service?
I found a way to do it. Basically have a singleton Service, which is a service with the android:singleUser="true" and with INTERACT_ACROSS_USERS and have the APK installed in /system/priv-app. Then have it broadcastAsUser to all users. You'll need to use reflection to access methods in UserManager. Then have a receiver instance which will receive the broadcast in the guest user's space, and then have the receiver startActivity.
There are several internal apis (comments as #hide) like Context.startActivityAsUser, NotificationManager.notifyAsUser to support it, but it needs build from source also with platform signature.
Everyone knows Tasker.
The optimal way to use Tasker would be to create a Plugin. But then you can't use other automation Apps like Llama (except you also build a plugin for them of course).
I saw a clever workaround for this. since nearly all automatisation Apps are able to start Intends, some Apps like the one for Franco.Kernel or ElementalX have classes which can be startet from such Apps to do Stuff. For ElementalX it looks like this: flar2.elementalxkernel.powersaver.DISABLE_POWERSAVE.
I like this idea and want to implement this to!
but I have some questions...
Are these just normal classes like every other Activity and Class in my Project?
How do I get my Context in those Classes?
Can those classes access all other functions and SharedPrefs in my App?
Is it possible to hand over parameters like Ints or Strings?
What else do I need to keep in mind?
The example you gave is an intent from the application ElementalX Kernel (now replaced by EX Kernel Manager)
The intent is made public by adding android:exported=“true” to the app's manifest. This means other apps like Tasker can use it.
Within the ElementalX Kernel app, there is a broadcast receiver that listens for this intent. When the intent is used, it triggers further actions. In your example, when the intent flar2.elementalxkernel.powersaver.DISABLE_POWERSAVE is broadcast, the app will receive the broadcast and call the methods that disable powersave mode.
I am writing an application to add all our apps to the homescreen of our devices. I need it to skip the apps that are services or contentproviders that just run in the background and are never "launched" by the user.
Any ideas? Right now i am specifying the apps, but would like to have it more automated.
Thanks!
See this thread for information on finding launchable Intent instances from the package manager.
I have been trying to figure this out on the web with no information whatsoever as to what this actually does. The Google Manifest information says:
Allows an application to set the maximum number of (not needed) application processes that can be running.
I am thinking this is not a third party app permission but I need to be sure, its for our embedded device.
My guess is that this limits the number of processes that one application can have open when calling android:process=".RemoteActivity" in the manifest.
Anyone? Thank you.
It's a development/debug intended permisson. And just do what it says. Remember that when you run an app, android creates a process for all it's activities. This is, if you start opening the different activities of your application, you use the same process. However, Android let's you choose if an activity uses the main process or another new one. That's why this permission exists.
Sources:
http://developer.android.com/guide/topics/fundamentals/processes-and-threads.html
http://developer.android.com/reference/android/Manifest.permission.html#SET_PROCESS_LIMIT