1.1 Enabling self-booting of the Android system
1.1.1. Implement your own broadcast receiver and implement the logic to be processed in the OnReceive () method
1.1.2. Androidmanifest.xml register the broadcast receiver, stating that the receiving broadcast filter is boot_completed broadcast
1.1.3. Declaration of authority
There is no very big difference between Android self-booting and general broadcast reception, but there are a few areas to note:
1. When using boot_completed broadcast, you must receive_boot_completed the permission, this is the change after 4.0
2. You can set the priority of the boot_completed broadcast by specifying the precedence property so that the app receives the broadcast before other apps
3. Under 4.4 boot_completed broadcast is an orderly broadcast, but not interruptible (specified Flag_receiver_no_abort field), and in 4.4 once, boot_completed broadcast
It's disordered.4. Because the package stopped flag is added after 4.0, the app in that state cannot receive boot_completed broadcasts when the status is generated by the following conditions:
A. Calling a hidden interface via reflection Forcestoppackage interface Stop Application
B. Disable button in Setting?application?detail, deactivated app
C. New installations, applications that have never been opened and executed
1.2 boot_completed broadcast the time of dispatch to understand the timing of the boot_completed broadcast, you must understand the Android startup process,
Get a quick overview of the Android boot sequence:
1 system boot, bootloader
2 Systemserver
3 AMS
4 Send Systemready Signal
5 Launcher Start
6 Send finishbooting Signal
7 Sending boot_completed broadcasts
1.3 Principle of prohibition of self-primingby understanding the timing and rationale of boot_completed broadcast, we can probably analyze several ways to disable self-booting:
1. Block apps from receiving boot_completed broadcasts, after 4.0, can be implemented by setting the app's package stopped flag (reflection calls the hidden Forcestoppackage method)
2. Block boot_completed broadcast by disabling the app's broadcast receiver, that is, set the component's Android:enable property to stop the receiver's response
3. The kill process to end the self-launched app
1.4 Methods of prohibiting self-booting1.4.1 Forcestoppackage
disabling by Forcestoppackage will not only deactivate the app's components, but also stop his timer, for the same time, the system privileges and the systems signature are required.
1.4.2 Disabling Component methods
The Android documentation for Android components has for example the following descriptive narration:
the<application> element has it own enabled attribute that applies to allapplication components, including Broadcas T receivers.
That is, we can set whether a component is enabled.
The following two methods are available in Packagemanager:
setapplicationenabledsetting can deactivate all of the components in the app.
The setcomponentenabledsetting is able to deactivate the specified component.
There are several points to note in this approach:
A. Compared to the Forcestoppackage interface, the interface does not empty the timer, and so on, only the component is enabled and deactivated, so it sends itself to define the broadcast in the timer, and specifies that Flag_exclude_stopped_packages is capable of waking the component in the broadcast.
B. Using the Setcomponentenabledsetting interface must be a system program and have a system signature
C. Need to affirm change_component_enabled_state authority
Usage:
Unfortunately, this method can only be changed to its own app, while the operation of the third-party app requires system permissions, even if root is not available, so we need to take advantage of packagemanager cmd implementation, namely PM command.
command requires root privileges: PM enable/disable package/package.class
1.4.3 Kill Process method
the most frequently used method is to kill the process through the Killbackgroundprocesses interface in the Activitymanager class, such as the following:
However, this method cleans up the process level is not too high, killprocess (PID) is a way to kill higher priority, but this method does not guarantee that the process is killed, because the method is only to send a kill process signal, the details whether to kill is In general, processes that can be killed, as determined by the system, such as the following:
A. Under-the-package process
B. The same UID process
C. Processes generated by the app at execution time
1.5 Find Boot boot permissions apkThere are many ways to find permissions, and here is just one way to do it by Packagemnager:
1.6 SummaryIn summary , the general self-priming management app in the market, mostly by the use of the PM command after root permission to disable the receiver containing the boot_completed, and others by monitoring the background process, polling to find the blacklist process to kill off the corresponding self-start program, not only the boot from the boot, but also to monitor the background self-booting, but the biggest problem with this method is to add system consumption, including memory consumption and power consumption.
Other third-party ROM also with rights management tools, such as Xiaomi's rights management system, is to resolve the permissions of the receiver, the priority of all receivers will be reduced by 1, so that the priority of other applications will always be lower than the priority of their system apps.
Through the survey found that the user cleanup process, the habit of controlling boot start from windows, process cleanup or control boot Startup items for Android system is not very significant, if an Android system is not root, then the third-party app The control of the system is basically not, the use of these software, on the one hand to reduce the security of Android system, on the other hand will also consume very large system resources, resulting in a vicious circle, mobile phone use more slowly.
Android Auto-boot Analysis
