Android restrictions on power-on self-boot

When it comes to how to get the program started, I think most friends will think it's a piece of cake, not just a boot_completed news!

Add a receiver to the androidmanifest.xml, like this:

<span style= "font-size:18px" >	<receiver android:name= "Bootreceiver" >
		<intent-filter>
			<action android:name= "Android.intent.action.BOOT_COMPLETED"/>
			<action android:name= " Com.android.settings.MAIL_SENT "/>
		</intent-filter>
	</receiver></SPAN>

Unfortunately, this is only valid for Android 2.3 and older versions, and in a new version of the Android system, this approach is not guaranteed to boot automatically.

First look at Google's official documentation:

 <span style= "font-size:18px" >launch controls on stopped applications to starting from Andro ID 3.1, the system ' s Package Manager keeps track of applications that are in a stopped state and provides a means of contr

Olling their launch from background processes and other applications. Note This application ' s stopped state isn't the same as activity ' s stopped state.

The system manages those two stopped states separately. The platform defines two new intent flags so let a sender specify whether the intent should is allowed to activate

Nents in stopped application.  Flag_include_stopped_packages-include Intent filters of STOPPED applications in the list of potential targets to resolve
Against.
Flag_exclude_stopped_packages-exclude Intent filters of STOPPED applications from the list of potential targets. When neither or both of these flags are defined in a intent, the default behavior is to include filters of stopped tions in the listof potential targets. This is 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 St oppped applications. A background service or application can override this behavior by adding the Flag_include_stopped_packages FLAG to BROADCA

St intents that should is allowed to activate stopped applications. Applications are in a stopped state when they are I installed but are not yet launched and then they are manually stop PED by the user (in Manage applications). </span> 

The above document is mainly about a few points:

1, Android 3.1 has a class of package called stopped package, they are the kind of installed but never started apk, or by the user in the program Management Force stop APK

2. A new set of FLAG (Flag_include_stopped_packages and Flag_exclude_stopped_packages) was added to the intent, with Flag_include_stopped_ Packages's intent does not work for stopped package.

3, the system of all the broadcast intent added flag:flag_exclude_stopped_packages, of course, boot complete broadcast is no exception.

After reading these 3 points, we should know why I said before: registration static receiver can not guarantee the app boot automatically.

The reason is simple, if my apk installed to the phone, has not been started by the user (or by the Force stop), then it is a stopped Package,boot_complete broadcast is unable to pull it up.

Here is a point to note:/system/app below APK are stopped package. So if your cell phone is root, it's another matter, you can push apk to System/app, but this installation is not the normal way to install.

So friends if you encounter apk can not boot automatically, please do not bother, first look at your Android version of it.

Why does Android have to join this mechanism?

Obviously for security reasons, since startup is the usual way of virus programs, this mechanism can prevent the virus program from starting up to a certain extent.