Summary of difficulties in realizing the function of an Android lock screen app

Customize a beautiful and practical lock screen app. If it can win the recognition of users and replace the lock screen of the system, it is definitely a big daily life entrance. This period of time just summarizes the difficulties in the development of lock screen app on Android platform recently investigated.

1、 Foreword

The general implementation principle of lock screen is very simple. Monitor the bright screen broadcast of the system. When the screen is bright, display your own lock screen interface. Users can unlock it only by a series of actions on the lock screen interface. Some mobile phone is too laggy to start the lock screen, so it will obviously see that the startup of the screen is delayed after the screen is lit. So you can also monitor the system's screen to screen out. When the screen is turned off, the screen is ready to be displayed, and your app will be easily killed.

It should also be noted that on screen and off screen broadcasting, screen_ ON/SCREEN_ Off can only be monitored dynamically, so it is necessary to open another service to register, and the self startup and maintenance of this service should also be done well.

I won't talk about the basic implementation details. This article will only talk about some difficulties encountered.

2、 Difficulties in the implementation of lock screen

1. Shield the home key

Since it is the lock screen interface, of course, the lock screen can only be unlocked through some sliding or input actions on the interface. It can't be unlocked simply by pressing the home key. Since 4.0, home has been responded by the system directly at the framework layer and forced back to the desktop. Third party applications can no longer pass through activity Onkeydown method to listen and intercept the home key. Although the keycode of the home key is symbolically reserved for forward compatibility, pressing the home key will not call back this method.

Besides onkeydown, is there any other way to listen to the home key? Yes. When the foreground app retreats to the background, there will be a broadcast action_ CLOSE_ SYstem_ Dialogs, after receiving the intent carried by the broadcast, parse the "reason" parameter to know the reason for exiting. After pressing the home key, reason is "home key", and after pressing the recent task key, reason is "recentapps".

This is certainly not the final plan, because some Samsung ROMs will not have this broadcast. And the broadcast just means to inform you that the framework layer has returned your application to the desktop. You can listen to the home key, but you can't intercept the home key. Maybe when I thought of listening to the home key, I immediately reopened my activity for display. I tried. After pressing the home key, the startactivity will delay for about 3 seconds. This should be Google's idea that we would do so and made such a delay scheme.

Direct interception doesn't work. Think of another way. Pressing the home key causes the system to return to the launcher (i.e. desktop launcher). If our lock screen activity itself is the launcher, pressing the home key does not mean returning to our lock screen activity, but also prevents it from turning off the lock screen activity.

How to declare your activity as a launcher and add an intent filter to the activity:

In this way, the newly installed app will be an app that can be used as a launcher. Therefore, when you press the home key for the first time, a pop-up window will prompt you to select which launcher to enter and select our own activity. In this way, the home key will be taken over by us.

However, there is an obvious problem. If you don't press the home key in our lock screen interface, you will also enter the lock screen activity. Of course, the solution is also simple. When we press home, we enter the oncreate of the lock screen activity to make a judgment. If the previous foreground activity is a lock screen activity, there is no need to process the home key. If it is not a lock screen activity, we need to close the lock screen activity and jump to the user's real desktop launcher. Which is the real desktop launcher? We can find it in this way:

If there is only one actual launcher, you can jump directly to the past:

If multiple launchers are installed on the mobile phone (such as apps such as 360 desktop), it will be a little troublesome. You need to display a list for users to choose which launchers to use. This may make users feel a little puzzled in terms of product form.

Now, if you press the home button in other apps, you will jump to our lock screen activity and then jump to the real launcher. There may be a flash of activity here, which will affect the user experience. In fact, the best way is to get another activity as the home key jump activity. If this activity is set to be transparent, it will not be perceived by the user. In this way, the product form becomes. Press the home key in the lock screen activity to jump to the transparent activity and back to the lock screen activity, which is equivalent to that the home key is invalid; Press the home key in other apps to jump to the transparent activity and to the real desktop.

To implement a transparent activity, you only need to declare it in XML

Such an interface is transparent. In fact, it occupies a space at the top of the screen, so remember to finish it after the jump, otherwise the interaction of the interface after the jump will be blocked. In addition, theme Nodisplay can also set the activity to be invisible and not occupy space. However, the author found that the activity of nodisplay cannot be set to launcher by the system (a window will pop up after setting, and so on)

2. Implementation mode of suspended window

Due to the limitation that the home key cannot be directly intercepted, the lock screen implemented by activity will need to go around more ways. Therefore, some lock screen applications will use the floating window. The floating window can ignore the home key and will not retreat to the background when pressing the home key. So there's no need to struggle with the home key. The suspended windows are uniformly managed by WindowManager. The specific implementation is relatively simple. I won't repeat it. Note that the suspended windows need to declare permissions:

In some mobile phone settings, the application is not authorized to use the suspended window by default, so the application should also consider guiding the user to authorize the suspended window.

In addition, there are some emergency unlocking scenarios, such as incoming call answering and alarm processing. For the lock screen interface implemented by activity, the system will automatically hide all foreground activities and let users deal with these scenarios directly. However, the suspended window will cover the scenes, so in case of these scenes, the lock screen interface implemented by the suspended window should handle the automatic unlocking of these special scenes by itself.

3. Disable the system lock screen

With its own lock screen interface, you also need to disable the lock screen of the system to avoid the situation that users need to unlock twice.

First, we need to know whether the user has set the lock screen. The method is as follows:

For API level 16 and above SDKs, you can use the following methods to determine whether there is a lock:

For API level 15 and the following SDKs, you can use reflection to judge:

Well, how can I turn it off when I know that the user has set the system lock screen? Some predecessors suggested this method

Permission required

However, after the author's test, this method can only disable the sliding lock. If the user sets a pattern or pin lock, it cannot be cancelled directly. Disabling password lock or pattern lock is a very dangerous behavior. Based on this, Google should not open it to developers. Therefore, the current method of disabling lock in lock screen applications is to directly jump to the system lock screen setting interface and directly guide users to manually close it. You can skip to the user lock screen setting interface through the following code:

There will also be some compatibility problems. For example, the ROM of 360 mobile phone does not put the function of setting the system lock screen in the security setting, so when you open the security setting interface, you can't find a place to cancel the system lock screen. This is not compatible in many lock screen applications.

3、 Difficulties in additional functions

The above functions are directly aimed at the implementation of the lock screen itself. In addition to the function of "locking the screen", the lock screen application should also have some other beautiful and practical functions. At least, it should try to get close to and play the style of the system lock screen, so as to be easily accepted by users.

1. Get notification

When a new notification arrives, it should be displayed on the lock screen interface, so we need to monitor the notification bar. Starting from Android 4.3 (API 18), Google has provided us with a notificationlistenerservice class. Third party applications can more easily obtain notification access. Of course, such sensitive permissions need to be declared by the application itself and guide users to authorize manually. As follows, create a notificationmonitor class, inherit from notificationlistenerservice, and declare permissions:

Then, like guiding the user to close the system lock screen, guide the user to authorize the use right of the notification bar:

You can check whether the right to use the notice column has been obtained through the following code:

After obtaining the right to use the notification bar, the changes of the system notification bar can be monitored in the notificationmonitor:

At the same time, notificationlistenerservice also provides cancelnotification and cancelallnotification methods to remove notifications in the notification bar, which can be easily removed in the customized lock screen interface.

When I implemented this class, I found a pit. All the code is OK, and the right to use the notification bar is authorized. However, when I came to the notification, I never called back onnotificationposted. I checked the problem for a long time. Later, I saw that someone on the Internet encountered the same problem. In addition, I built a new class to copy the code. It's OK. It seems that it should be a compiler problem.

The service that has obtained the right to use the notification bar can naturally be kept alive. If it is killed, the Android system can restart it. Therefore, when you see some applications asking for permission to use the notification bar, you should note that such applications will be permanently stored in the background. Of course, if the process where the service is located crashes a certain number of times, the Android system will also lose heart and will not restart the service before the next shutdown and restart. Therefore, it is best to put the service in a lightweight and independent process during development.

2. Get hotseat area shortcut

Desktop shortcuts are divided into two categories: the desktop area refers to the part that scrolls with the screen, and the hotseat area refers to the part placed at the bottom of the desktop that does not scroll with the screen. User defined shortcuts in the hotseat area are common applications. If you can also add this part of the quick start in the lock screen interface, it will be a more friendly function. The main problem with this is how to get a shortcut to the hotseat area.

The system shortcut is stored in the database file launcher In the favorites table in dB, as shown in the figure:

In other words, the shortcut to the desktop area with container - 100 and the shortcut to the hotseat area with container - 101.

Now that you know how to store shortcuts, the next problem is to find the launcher The path to the DB file.

In different versions of Android native APIs, since the package name of the launcher launcher used by default is different, launcher The path of DB storage is also different.

Android API 7 and below: / data / data / com android. launcher/databases/laucher. db Android API 8~18：/data/data/com. android. launcher2/databases/laucher. DB Android API 19 and above: / data / data / com android. launcher3/databases/laucher. db

For all kinds of third-party ROMs, the use of strange laucher package names makes the path even more chaotic:

HTC: /data/data/com. htc. launcher/databases/laucher. db 360: /data/data/net. qihoo360. launcher/databases/laucher. DB Huawei: / data / data / com huawei. launcher3/databases/laucher. DB Xiaomi: / data / data / com miui. mihome2/databases/laucher. db ...

Of course, we will not obtain the shortcut information by directly reading the database. The laucher provided by the system will provide the ContentProvider for external reading. It avoids the pit of compatibility with the database path and falls into another pit in the blink of an eye. The required permissions and URIs need to be compatible to read shortcuts through the provider.

From the storage of shortcuts, we can see how serious the fragmentation of Android is, so finally, the author decided not to go deep into compatible implementation, which is not worth the loss. If you are interested in implementation, you can see this article to judge how difficult it is to determine whether a shortcut exists: http://www.jianshu.com/p/dc3d...

3. Get wallpaper

The background of the lock screen interface is consistent with the mobile phone desktop wallpaper, so as not to make users feel abrupt. Here are two ways to obtain the wallpaper.

Activity style mode

If it is the lock screen interface implemented by the activity, you can directly set the theme of the activity and use the wallpaper as the background.

Wallpapermanager mode

If theme cannot be used in the lock screen interface of suspended window mode, you can obtain wallpaper through wallpapermanager.

This method is OK on Xiaomi's one screen desktop imitating IOS, but on the two screen desktop like native Android (the shortcut and all apps are on different screens). The wallpaper obtained from the shortcut screen is a whole large wallpaper, while the actual laucher displays the cut wallpaper. Therefore, the wallpaper with inconsistent size will be set as the background in the above methods. You need to cut the picture according to the number of laucher screens and the current screen. The total number of laucher screens can be found in the work in the above launcher.db It can be found in the spacescreens table. The specific screen currently exists in the launcher app memory instance and cannot be obtained. If you really want to cut it, it is recommended to cut the left screen of the whole wallpaper directly according to the screen width and height.

The above is the whole content of this article. I hope it will be helpful to your study, and I hope you can support programming tips.