Android Auto-Boot Analysis,

Android Auto-Boot Analysis,
1.1 enable 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. register the broadcast receiver in AndroidManifest. xml and declare that the receiving broadcast filter is Boot_Completed broadcast.



1.1.3. Declare Permissions



There is no big difference between auto-start and normal Broadcast Reception for Android, but there are some points to note:
1. When BOOT_COMPLETED broadcast is used, the RECEIVE_BOOT_COMPLETED permission must be required, which is modified after 4.0.
2. You can set the BOOT_COMPLETED broadcast priority by specifying the priority attribute so that the app receives broadcasts earlier than other apps.
3. In 4.4, BOOT_COMPLETED broadcast is an ordered broadcast, but cannot be interrupted (the FLAG_RECEIVER_NO_ABORT field is specified). Before 4.4, BOOT_COMPLETED Broadcast
Is unordered 4. Because the Package stopped flag is added after 4.0, the app in this status cannot receive the BOOT_COMPLETED broadcast. This status is generated in the following situations:
A. Call the hidden API forceStopPackage through reflection to stop applications.
B. Click the disable button in settingapplicationdetail to disable the application.
C. Newly Installed applications that have never been opened or run

1.2 When BOOT_COMPLETED broadcast is sent, you must understand the Android startup process when BOOT_COMPLETED broadcast is sent,
Brief Introduction to the Android startup sequence:

1. system startup, bootloader
2 SystemServer
3 AMS
4 Send systemReady Signal
5 Launcher start
6 Send finishBooting Signal
7 send BOOT_COMPLETED Broadcast

1.3 The principle of disabling auto-start by understanding the time and principle of BOOT_COMPLETED broadcast sending, we can analyze several methods to disable auto-start:
1. Prevent the app from receiving the BOOT_COMPLETED broadcast. After 4.0, you can set the app Package stopped flag (reflection calls the hidden forceStopPackage method)
2. Disable the broadcast receiver of the application to block the BOOT_COMPLETED broadcast. That is, set the android: enable attribute of the component to stop the response of the receiver.
3. Run the kill process to stop the self-started app.


1.4 Method for disabling auto-start 1.4.1 forceStopPackage
By using forceStopPackage, not only will the app components be disabled, but also its timer will be stopped. At the same time, the system permission and system signature are required.


1.4.2 deactivating Components
Android components are described as follows:
The <application> element has its own enabled attribute that applies to allapplication components, including broadcast receivers.
That is, you can set whether a component is enabled.
PackageManager provides the following two methods:






SetApplicationEnabledSetting can disable all components in the application.
SetComponentEnabledSetting can disable a specified component.
This method has the following considerations:
A. compared with the forceStopPackage interface, this interface does not clear the timer, but only enables or disables components. Therefore, it sends custom broadcasts in the timer and specifies FLAG_EXCLUDE_STOPPED_PACKAGES in the broadcast to wake up the component.
B. The setComponentEnabledSetting interface must be a system program with a system signature.
C. Declare the CHANGE_COMPONENT_ENABLED_STATE permission.
Usage:



Unfortunately, this method can only be modified for your own app, and operating on a third-party app requires system permissions, even root cannot be used. Therefore, we need to use the cmd Implementation of packagemanager, that is, the PM command.
Root permission is required for the command: pm enable/disable package/package. class

1.4.3 Kill Process Method

The most common method is to killBackgroundProcesses interface in the ActivityManager class to kill the process. The common code is as follows:



However, the process level to be cleared by this method is not too high. killProcess (pid) is a method that can kill higher priority. However, this method cannot guarantee that the process is killed, because this method only sends the kill process signal, whether or not kill is determined by the system. Generally, the process that can be killed is as follows:
A. process under the same package
B. processes with the same uid
C. processes generated when the app is running

1.5 There are many ways to find the apk permission for the startup permission. Here, only one method is provided, that is, through packagemnager:




1.6 In summary, most of the Self-started management apps on the market are implemented by disabling the receiver containing Boot_Completed by using the pm command after obtaining the root permission, and some are implemented by monitoring the background process, poll the process in the blacklist to kill the corresponding self-starting program, including not only starting the system, but also monitoring the background self-starting. However, the biggest problem with this method is that it increases system consumption, including memory consumption and power consumption. In addition, some third-party ROM also has permission management tools. For example, Xiaomi's permission management system reduces the priority of all receivers by 1 when parsing the receiver's permissions, in this way, the priority of other applications will always be lower than that of their system apps.
The investigation found that the user's habit of cleaning up the process and controlling start-up is from windows. process cleaning or controlling start-up items is of little significance to the Android system, if an Android system is not root, the third-party app has no permission to control the system. Using these software reduces the security of the Android system, on the other hand, it will also consume a lot of system resources, resulting in a vicious circle, the more slow the use of mobile phones.