Recently, I am working on a project to implement a device control software app. It is necessary to start the app after the phone is turned on and pull out the privacy page for the user to sign, so as to start the control of the device.

Of course, this is a special app. Strongly relies on the support of the underlying software environment. It is not consistent with the market app, so it is for reference only.

I. When it comes to boot, the first thing that comes to mind is to monitor the boot broadcast of the system and pull up the app.

First, you need to in AndroidManifest listing file. The XML application listening on radio access android. Intent. Action. The BOOT_COMPLETED.

<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED"/>
Copy the code

Then declare the broadcast receiver in the manifest file AndroidManifest.xml, which is the BootReceiver class that implements listening to the broadcast and processing its own business logic (pulling up its own app).

<receiver android:name=".base.BootReceiver"> <intent-filter> <action android:name="android.intent.action.BOOT_COMPLETED"  /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </receiver>Copy the code

Finally achieve a BroadcastReceiver, the radio receiver listening “android. Intent. Action. BOOT_COMPLETED” radio, when receives the broadcast, open the start page of the application.

public class BootReceiver extends BroadcastReceiver { @Override public void onReceive(Context context, Intent intent) { if (intent.getAction().equals("android.intent.action.BOOT_COMPLETED")) { Intent toIntent = context.getPackageManager().getLaunchIntentForPackage(context.getPackageName()); context.startActivity(toIntent); }}}Copy the code

The above three simple operations to complete the monitoring, the implementation of business code. But you may not be able to listen to the boot broadcast even if you do exactly as above. I called the underlying software interface to add a super whitelist to my app, so I can listen to the boot broadcast.

Another thing to note is that the first time you need to start the app, the next startup restart can be monitored. The app I developed will end with the user setting the gesture when the device is restored to factory Settings. Also known as ooBE phase, MP system will pull up our app. This also solves the problem that you need to manually open the app before listening takes effect.

Normally, the above requirements are basically completed. However, in the test, it was found that the app was not pulled up when the user set the gesture to end when the factory was restored. By viewing the system log, it is found that the boot broadcast comes out shortly after the device is turned on, that is, after the user selects the system language after the factory Settings are restored. The user then sets the end of the gesture, which means the OOBE phase is over and the app cannot be pulled up.

To sum up: After normal startup and restart, the app can automatically start by listening to the startup broadcast. However, when the factory Settings are restored, the startup broadcast will be issued before the user completes gesture navigation. When the user enters the desktop after gesture navigation, the app cannot be pulled up.

Listen to the ContentObserver and pull up the app

To handle the pull up app in the factory reset case above. We’ll have to find another way. At this time, you can find out that most people use the two parameters “user_setu_complete” and “device_provisioned”, but find that “user_setu_complete” cannot be obtained during the process. Finally, I use “device_provisioned”.

The idea is that you can communicate by changing the properties of the system database when passing status values. Set device_provisioned=0 when restoring factory Settings. After user OOBE ends, MP system will set device_provisioned=1. We can listen for changes in the Device_provisioned value through onChange in ContentObserver to meet business requirements.

Register listeners in the application class:

/ / registered mContext. GetContentResolver (). RegisterContentObserver (Settings) System. GetUriFor (" device_provisioned "), false, mDeviceProvisionedObserver); / / unbundling mContext. GetContentResolver () unregisterContentObserver (mDeviceProvisionedObserver);Copy the code

Realize the ContentObserver class processing business:

private ContentObserver mDeviceProvisionedObserver=new ContentObserver(new Handler()) { public void onChange(boolean SelfChange) {// listen for device_provisioned=1 and pull up app}; };Copy the code

Plus listen to the ContentObserver above, and boot broadcast BOOT_COMPLETED. So the function is complete.

3. To summarize

In summary: OOBE restores factory Settings by listening to the ContentObserver and pulling up the app; After the normal power button of the device restarts, go to listen for BOOT_COMPLETED, and pull up the app.

The end scatter flowers!!