I know that in applications developed by third parties to get on google play, BroadcastReceiver not begin to run until the user enters the application.
I would like to know what happens in applications that are pre installed on the phone, because I am developing an application of this type. They start to listen from the beginning or require the user to enter the application?
System apps receive broadcasts, even if they are in force stopped state or have not been started even once
Edit :
PackageManagerService has a ActivityIntentResolver which resolves all the broadcasts. So if you check the override for isFilterStopped, it is excluding system apps from stopped packages.
Below is the comment you can search in AOSP:
// System apps are never considered stopped for purposes of
// filtering, because there may be no way for the user to
// actually re-launch them.
Related
I have a device management application, which essentially runs as a service in the background from boot. I'd like to start this application immediately after installation. How do I achieve this?
You cannot do this -- there is no way to automatically start your service merely because it was installed.
The application must first be invoked by the user through some sort of activity. Or, you are going to need to hook into some relevant broadcast Intent via the manifest, so you can get control when one of those events occur and kick off your service that way. Or, you are going to need to ask the user to reboot so your BOOT_COMPLETED Intent filter can get control.
There was a hole - the Android Analytics SDK used to send an intent right after installation - but that got closed (producing lots of confusion, of course).
But the final answer, I believe, is here:
http://developer.android.com/about/versions/android-3.1.html#launchcontrols
This seems to suggest that, as of 3.1, Google made the decision that apps are in a stopped state until the user explicitly activates them, e.g. by launching app or placing widget.
This means that the strategy of listening of a common broadcast (i.e. to get your app launched surreptitiously) won't work either.
I'm looking for technical input on Android User Profiles (both full & restricted). More specifically I would like to understand:
Whether it is possible to create an app which runs across all profiles, i.e. is not stopped, paused, restarted when switching user profile. My focus is NOT limited to activities, but I'm also interested in knowing whether a system-app/service could be created that does this and if so how.
What life-cycle is maintained for services of the non-active users. I get the impression that (at least some) services of APKs of a user get started the moment it gets activated in the lock screen (even without unlocking) and then are allowed to keep on running. But what will happen in low-memory conditions? Will a service of a non-active user also receive broadcast intents? Can such a service interact with the user and if so how?
In general: can someone point me to any technical information on the Android profiles features? There's a lot of articles on how it "looks" to the user, but I could find very little (apart from info on the pm and am command-line tools' options) on how it really works technically.
Thanks in advance!
Whether it is possible to create an app which runs across all profiles, i.e. is not stopped, paused, restarted when switching user profile. My focus is NOT limited to activities, but I'm also interested in knowing whether a system-app/service could be created that does this and if so how.
Default Android behaviors
By default, an Android application runs in a specific Android user workspace, it does not run for all Android users.
It means that when the user starts an application, it is started for the current Android user only.
When the application is launched from another Android user, Android will recreate a new instance of your application. As Android users can run in the background it means that you can have several instances of the same aplication running in parallel.
All the Android components of you application (ie. Services, Activities, BroadcastReceivers and ContentProviders) will be re-instantiated.
Most of the time it's the wanted behavior, but it can be a problem for some applications that do system-level handlings that have to be done once for the whole system, without
taking into account Android users (ex: a JobService doing some handling on Bluetooth events).
Define a singleton component/application
For each component of your app which is not an Activity, you have the possibility to specify that you want it to run as a singleton (ie. only one instance will be created for all Android users.).
To do so, the property android:singleUser=”true” must be added to the attributes of the component in the AndroidManifest.xml of the application.
<!-- Declare a singleUser service in the AndroidManifest.xml -->
<service
android:name=".MySingleUserService"
android:singleUser="true" />
Any singleUser component will always run under the system Android user (ie. the user 0) which can't be stopped by Android, even if you're application is currently running for another Android user.
To be able to use the property android:singleUser=”true”:
your app has to be a system application (either in system/app/ or system/priv-app/).
you app has to be signed by the platform certificate (by specifying LOCAL_CERTIFICATE := platform in its Android.mk).
your app must declare the use of the following permission in its AndroidManifest.xml.
<!-- Permission needed to use android:singleUser. -->
<uses-permission android:name="android.permission.INTERACT_ACROSS_USERS"/>
Additional remarks
If your app only contains singleUser components, the entire app will become singleUser (ie. only one instance of your app will run for the entire system).
android:singleUser=”true” forces android:exported=”false” for your component (except if your app is privleged).
If a component of your application wants to communicate with a singleUser component of the same app via Intents, the default Android APIs can't be used because Intents do not cross Android users.
In that case, you have to use the multi-user Intent exchanges dedicated APIs which are suffixed by AsUser (ex: sendBroadcastAsUser(), startServiceAsUser(), etc.) and which allow to specify the destination Android user (UserHandle.SYSTEM in that case). Note that one of the following permissions must be used:
<!-- Permission needed to send intents to components of the SAME app running in another Android user. -->
<uses-permission android:name="android.permission.INTERACT_ACROSS_USERS"/>
<!-- Permission needed to send intents to components of ANOTHER app running in another Android user. -->
<uses-permission android:name="android.permission.INTERACT_ACROSS_USERS_FULL"/>
What life-cycle is maintained for services of the non-active users. I get the impression that (at least some) services of APKs of a user get started the moment it gets activated in the lock screen (even without unlocking) and then are allowed to keep on running. But what will happen in low-memory conditions? Will a service of a non-active user also receive broadcast intents? Can such a service interact with the user and if so how?
As I've mentionned above, an Android user can continue to run in the background even if they are not the active one (at least until Android 10). If resources are low, Android can stop any Android user which is not the system user (ie. stop all their running applications). So a Service can continue to run on an Android user which is currently running in the background until the user is stopped.
As I've also mentioned above, Intents do not cross Android users. So if you have a BroadcastReceiver registered in the user 10 and that an Intent is sent from the user 11, it won't be received by your BroadcastReceiver. The only exception is if you use the AsUser Intent exchanges APIs to send it.
Also note that an Intent with the action BOOT_COMPLETED is sent whenever a new Android user is started. It is only sent to the components of the starting Android user.
Sources
Unfortunately, there is few Android online documentation about multi-user systems. Here are the only articles about it (if youd don't find answers there, I suggest you to directly look into the AOSP source code):
Building Multiuser-Aware Apps
Supporting Multiple Users
Manage multiple users
I have developed a Service for Android that starts when BOOT_COMPLETED is received.It works fine on versions prior to 3.1.
I newer versions tough I understand the application must be launched in order to receive this broadcast . How can I launch my application if I don't have an User Interface ?
You add a user interface, in the form of an activity that the user can launch. Besides, this is where you need to:
Allow the user to stop and start your service, since the user may not want your service to be running 24x7 and you do not want the user to have to resort to Force Close
Display your documentation
Display your license agreement
I want to disable/unregister intents registered by other apps so that they would not get broadcast messages sent by the system?
Something like this:
Gemini app
(3rd screenshot)
Is there any similar app with the open source code?
Also, it is possible to remove permissions registered by another app?
I want to disable/unregister intents registered by other apps so that they would not get broadcast messages sent by the system?
Fortunately, that is not possible, except on rooted devices.
Something like this: Gemini app (3rd screenshot)
As the app notes, this requires root.
Also, it is possible to remove permissions registered by another app?
As JonTraex notes in his linked-to answer, this is not possible even with root.
I answered a similar question here:
https://stackoverflow.com/a/9106832/529691
If you had bothered to look at their permissions you could see how they are doing it.
SYSTEM TOOLS
KILL BACKGROUND PROCESSES Allows an application to kill background
processes of other applications, even if memory isn't low.
KILL BACKGROUND PROCESSES Allows an application to kill background
processes of other applications, even if memory isn't low.
FORCE STOP OTHER APPLICATIONS Allows an application to forcibly stop
other applications.
MEASURE APPLICATION STORAGE SPACE Allows an application to retrieve
its code, data, and cache sizes
i need to perform an action when my application is installed. i've looked into using
Intent.PACKAGE_ADDED
but i don't receive the intent in the app that's being installed. i want to run code when my app is installed for the first time.
the use case is registering with an online service. i can listed for BOOT_COMPLETED which is fine if the app is already installed, but i need to handle the case when the user first installs the app.
this post,
Can you run an intent or script when your app gets installed on Android?
suggests listening to TIMER_TICK and on the first broadcast, perform the registration and set a flag so as not to perform it upon the next TIMER_TICK. this seems problematic because whether you do something or not in the receiver, you are still starting your receiver every single minute and using up battery in the process.
is there a better solution?
There is no reliable event that you can catch. Even TIMER_TICK will only work below Android 3.1. From 3.1. onwards you can't receive system broadcasts until your app is in active state (which means the user has to launch it at least once manually).
Launch controls on stopped applications
Starting from Android 3.1, the system's package manager keeps track of
applications that are in a stopped state and provides a means of
controlling their launch from background processes and other
applications.
[...]
Note that the system adds FLAG_EXCLUDE_STOPPED_PACKAGES to all
broadcast intents. It does this to prevent broadcasts from background
services from inadvertently or unnecessarily launching components of
stoppped applications.
[..]
Applications are in a stopped state when they are first installed but
are not yet launched and when they are manually stopped by the user
(in Manage Applications).
from the 3.1. release notes
I recommend to do your intitial work when the user starts your app for the first time.
With the new market, the INSTALL_REFERRER intent is fired at launch time now for Android 3.1 and above. So we can receive it in our app. However it still fires at install time for 2.2 when the app is in stop state. So I am not able to receive it in case of Froyo.
If you're willing to assume that the Google Android Market app is installed, you could use INSTALL_REFERRER. See Get referrer after installing app from Android Market for more info.