实现一个Android锁屏App的难点总结

移动开发 Android
自定义一个漂亮实用的锁屏app,如果能赢得用户的认可,替换系统自带的锁屏,绝对是一个不小的日活入口。这段时间正好总结一下最近调研的Android平台的锁屏app开发中的难点。

自定义一个漂亮实用的锁屏app,如果能赢得用户的认可,替换系统自带的锁屏,绝对是一个不小的日活入口。这段时间正好总结一下最近调研的Android平台的锁屏app开发中的难点。

一、前言

锁屏的大概实现原理都很简单。监听系统的亮屏广播,在亮屏的时候展示自己的锁屏界面,用户在锁屏界面上进行一系列的动作才能解锁。有的手机启动锁屏界面的过程会很卡,所以会明显看到亮屏之后锁屏界面的启动有延时,因此也可以选择监听系统灭屏的广播,屏幕关掉的时候就将锁屏界面准备好,直接亮屏展示(灭屏后你的app会比较容易被杀死,这点要注意做保活)。

还需要注意,亮屏和灭屏广播,SCREEN_ON/SCREEN_OFF都是只能动态监听的,所以要另开一个Service来注册,这个Service的自启动和保活也要做好。

基本的实现细节就不多讲了,这篇文章只会讲遇到的几个难点。

二、锁屏实现中的难点

1.屏蔽Home键

既然是锁屏界面,当然只能通过界面上的一些滑动或者输入动作来解开锁屏,不能简单的直接被Home键一按,就解开了。从4.0开始,Home直接在framework层就被系统响应到,强退到桌面,第三方应用里已经无法再通过Activity.onKeyDown方法来监听和拦截Home键,尽管还象征性的保留了Home键的KeyCode来向前兼容,但是Home键按下去,并不会回调这个方法。

除了onKeyDown,有没有其他办法监听Home键,有的。前台App退到后台会有广播ACTION_CLOSE_SYSTEM_DIALOGS,收到广播携带的intent之后,解析里面的"reason"参数,就可以知道退出原因是什么了。home键按下后,reason是"homekey",最近任务键按下后,reason是"recentapps"。

这当然不是最终方案,因为有些三星ROM里并不会有这个广播。而且广播的意思只是通知你一下,人家framework层已经把你的应用退回桌面了,你能监听home键,但没有办法拦截home键。也许想到了可以监听到home键的时候,马上把自己的Activity又重新打开展示,我试了一下,home键按下后startActivity会有延时3秒左右,这应该是Google早就想到了我们会这么干,做了这么一个延时方案。

直接拦截行不通了,想想别的路子。按Home键是让系统退回到Launcher(即桌面启动器),那么如果我们的锁屏Activity本身就是Launcher的话,那按Home键不就等于回到我们的锁屏Activity,也就可以阻止它把锁屏Activity关掉了。

怎么把自己的Activity声明为Launcher,在Activity中添加intent-filter:

  1. <intent-filter> 
  2.  
  3. <action android:name="android.intent.action.MAIN" /> 
  4.  
  5. <category android:name="android.intent.category.HOME" /> 
  6.  
  7. <category android:name="android.intent.category.DEFAULT" /> 
  8.  
  9. </intent-filter>  

这样,新安装的app会是一个能够作为launcher的app,所以首次按Home键的时候,就会有弹窗提示你选择要进入哪个launcher,选择我们自己的Activity,这样home键就被我们接管了。

不过这样有一个很明显的问题,如果不在我们的锁屏界面按Home键,同样会进入到锁屏Activity。当然,解决的方式也简单,当我们按Home时进入锁屏Activity的onCreate里做一个判断,如果前一个前台Activity是锁屏Activity,那就不用对Home键处理,如果不是锁屏Activity,那就要关闭锁屏Activity,跳到用户真正的桌面启动器去了。真正的桌面启动器是哪一个,我们可以这样来找:

  1. List<String> pkgNamesT = new ArrayList<String>(); 
  2. List<String> actNamesT = new ArrayList<String>(); 
  3. List<ResolveInfo> resolveInfos = context.getPackageManager().queryIntentActivities(intent, PackageManager.MATCH_DEFAULT_ONLY);   
  4. for (int i = 0; i < resolveInfos.size(); i++) { 
  5.     String string = resolveInfos.get(i).activityInfo.packageName; 
  6.     if (!string.equals(context.getPackageName())) {//自己的launcher不要       
  7.         pkgNamesT.add(string); 
  8.         string = resolveInfos.get(i).activityInfo.name
  9.         actNamesT.add(string); 
  10.     } 
  11.  

如果实际的launcher只有一个,那直接跳转过去就可以了:

  1. ComponentName componentName = new ComponentName(pkgName, actName);  
  2. Intent intent = new Intent();  
  3. intent.setComponent(componentName);  
  4. context.startActivity(intent);  
  5. ((Activity) context).finish();  

如果手机安装有多个launcher(如360桌面一类的app)就会麻烦一点,需要展示一个列表让用户来选取用哪个launcher,这个在产品形态上可能会让用户觉得有点不解。

现在,如果在其他APP里按一下Home键,会跳到我们的锁屏Activity然后跳转到真正的launcher。这里可能会有Activity闪现一下的场景,影响用户体验。最优的办法其实是另外弄一个Activity来作为Home键跳转的Activity,这个Activity设为透明的,就不会被用户感知。如此,产品形态就变成了,锁屏Activity中按Home键,跳转到透明Activity,跳转回锁屏Activity,相当于Home键无效;其他APP中按Home键,跳转到透明Activity,跳转到真正的桌面。

实现透明的Activity,只需要在xml中声明

  1. android:theme="@android:style/Theme.Translucent.NoTitleBar" 

这样的界面是透明的,实际上有占位在屏幕的顶层,所以跳转后记得要finish掉,不然会阻断跳转后的界面的交互。另外,Theme.NoDisplay也能将Activity设置为不可见,而且不占位,但是笔者实现的时候发现,NoDisplay的Activity无法被系统设置为launcher(设置后会弹窗让你重新设置,如此反复)

2.悬浮窗的实现方式

由于受Home键无法直接拦截的限制,Activity实现的锁屏会需要绕较多的路。所以有的锁屏应用会使用悬浮窗来实现,悬浮窗能够无视Home键,在按下home键的时候不会退到后台。所以不需要在home键的问题上纠结。悬浮窗统一由WindowManager来管理,具体的实现比较简单,笔者就不赘述了,有个坑要注意,悬浮窗需要声明权限:

  1. <uses-permission android:name="android.permission.SYSTEM_ALERT_WINDOW" /> 

有的手机设置里,默认是不给应用授权悬浮窗使用权的,所以应用里还要考虑引导用户授权悬浮窗使用。

此外,有些应急解锁的场景,比如来电接听,闹铃处理,对于Activity实现的锁屏界面,系统会自动把所有的前台Activity隐藏,让用户直接去处理这些场景。但是悬浮窗会盖住场景,所以遇到这些场景,悬浮窗实现的锁屏界面要自己去处理这些特殊场景的自动解锁。

3.禁用系统锁屏

有了自己的锁屏界面,还需要禁用掉系统的锁屏,以免造成用户需要解锁两次的局面。

首先我们需要知道用户是否设置了锁屏,方法如下:

对于API Level 16及以上SDK,可以使用如下方法判断是否有锁:

  1. ((KeyguardManager) getSystemService(Context.KEYGUARD_SERVICE)).isKeyguardSecure() 

对API Level 15及以下SDK,可以使用反射来判断:

  1. try { 
  2.     Class<?> clazz = Class.forName("com.android.internal.widget.LockPatternUtils"); 
  3.     Constructor<?> constructor = clazz.getConstructor(Context.class); 
  4.     constructor.setAccessible(true); 
  5.     Object utils = constructor.newInstance(this); 
  6.     Method method = clazz.getMethod("isSecure"); 
  7.     return (Boolean) method.invoke(utils); 
  8. }catch (Exception e){ 
  9.     e.printStackTrace(); 
  10.  

好了,得知用户设置了系统锁屏,怎么关掉呢?有前人建议了这种方法

  1. KeyguardManager km = (KeyguardManager) getSystemService(Context.KEYGUARD_SERVICE); 
  2. KeyguardManager.KeyguardLock keyguardLock = km.newKeyguardLock(""); 
  3. keyguardLock.disableKeyguard();  

需要权限

  1. <uses-permission android:name="android.permission.DISABLE_KEYGUARD" /> 

但经笔者测验,这种方法只能禁用滑动锁,如果用户设置的是图案或者PIN的锁的话,是无法直接取消的。禁用掉密码锁或者图案锁是一个很危险的行为,基于此,Google应该是不会把它开放给开发者的,所以现在的锁屏应用的禁用锁的办法,都是直接跳到系统锁屏设置界面,直接引导用户去手动关闭。可以通过如下代码跳到用户锁屏设置界面:

  1. Intent in = new Intent(Settings.ACTION_SECURITY_SETTINGS); 
  2. startActivity(in);  

这个也会有些许的兼容性问题,比如,360手机的ROM并没有把设置系统锁屏的功能放在安全设置中,所以打开安全设置的界面找不到取消系统锁屏的地方,这个在一众锁屏应用中并没有做兼容。

三、附加功能中的难点

上面的功能都是直接针对锁屏本身的实现来说的。锁屏应用除了本身能够有“锁住屏幕”的功能外,还应该有其他一些漂亮又实用的功能,最起码应该是尽量往系统锁屏的样式上靠拢并发挥,才方便被用户接受。

1.获取通知

新的Notification到来时应该展示在锁屏界面上,所以我们需要对通知栏进行监听。从Android 4.3(api 18)开始,Google给我们提供了一个NotificationListenerService类,第三方应用可以更方便的获得通知栏使用权(Notification Access),当然,这么敏感的权限得要应用自己声明,同时还要引导用户手动授权。如下,建立一个NotificationMonitor类继承于NotificationListenerService,并声明权限:

  1. <service android:name=".NotificationMonitor" 
  2.  
  3. android:permission="android.permission.BIND_NOTIFICATION_LISTENER_SERVICE"
  4.  
  5. <intent-filter> 
  6.  
  7. <action android:name="android.service.notification.NotificationListenerService" /> 
  8.  
  9. </intent-filter> 
  10.  
  11. </service>  

然后同引导用户关闭系统锁屏一样,要引导用户来授权通知栏使用权:

  1. startActivity(new Intent(Settings.ACTION_NOTIFICATION_LISTENER_SETTINGS)); 

可以通过如下代码检查到通知栏使用权是否已经拿到:

  1. private boolean isNotificationListenEnabled(){ 
  2.         String pkgName = getPackageName(); 
  3.         final String flat = Settings.Secure.getString(getContentResolver(), 
  4.                 "enabled_notification_listeners"); 
  5.         if (!TextUtils.isEmpty(flat)) { 
  6.             final String[] names = flat.split(":"); 
  7.             for (int i = 0; i < names.length; i++) { 
  8.                 final ComponentName cn = ComponentName.unflattenFromString(names[i]); 
  9.                 if (cn != null) { 
  10.                     if (TextUtils.equals(pkgName, cn.getPackageName())) { 
  11.                         return true
  12.                     } 
  13.                 } 
  14.             } 
  15.         } 
  16.         return false
  17.     }  

拿到通知栏使用权后,系统通知栏的变化就可以在NotificationMonitor里面监听到了:

  1. public class NotificationMonitor extends NotificationListenerService { 
  2.     @Override 
  3.     public IBinder onBind(Intent intent) { 
  4.         // TODO: Return the communication channel to the service. 
  5.         return null
  6.     } 
  7.  
  8.     @Override 
  9.     public int onStartCommand(Intent intent, int flags, int startId) { 
  10.         return super.onStartCommand(intent,flags,startId); 
  11.     } 
  12.  
  13.     //新的Notification到达 
  14.     @Override 
  15.     public void onNotificationPosted(StatusBarNotification sbn) { 
  16.         super.onNotificationPosted(sbn); 
  17.     } 
  18.  
  19.     //新的Notification到达,api 21新增 
  20.     @Override 
  21.     public void onNotificationPosted(StatusBarNotification sbn, RankingMap rankingMap) { 
  22.         super.onNotificationPosted(sbn, rankingMap); 
  23.     } 
  24.  
  25.     //Notification被移除 
  26.     @Override 
  27.     public void onNotificationRemoved(StatusBarNotification sbn) { 
  28.         super.onNotificationRemoved(sbn); 
  29.     } 
  30.  
  31.     //Notification被移除,api 21新增 
  32.     @Override 
  33.     public void onNotificationRemoved(StatusBarNotification sbn, RankingMap rankingMap) { 
  34.         super.onNotificationRemoved(sbn, rankingMap); 
  35.     } 
  36.  
  37.     //Notification排序变动,api 21新增 
  38.     @Override 
  39.     public void onNotificationRankingUpdate(RankingMap rankingMap) { 
  40.         super.onNotificationRankingUpdate(rankingMap); 
  41.     } 
  42.  
  43.     //Service与系统通知栏完成绑定时回调,绑定后才能收到通知栏回调,api 21新增 
  44.     @Override 
  45.     public void onListenerConnected() { 
  46.         super.onListenerConnected(); 
  47.     } 
  48.  

同时,NotificationListenerService还提供了cancelNotification和cancelAllNotification方法,用于移除通知栏的通知,可以很方便的实现在自定义的锁屏界面移除掉通知了。

笔者实现这个类的时候发现了一个坑,所有的代码都是OK的,通知栏使用权也授权了,但是来通知时始终没有回调onNotificationPosted,查问题查了很久,后来看到网上有人遇到同样的问题,另外新建了一个类把代码复制过去,就OK了,这样看来应该是编译器的问题。

获取了通知栏使用权的Service天然就能被保活,如果被杀死,Android系统能够将它重启。所以平时看到一些应用要求获取通知栏使用权时,要注意这类应用会永久驻存后台的。当然,如果这个Service所在进程崩溃达到一定次数的话,Android系统也会灰心,在下次关机重启前不会再将Service重启,所以,开发中最好能将这个Service放在一个轻量独立的进程中。

2.获取HotSeat区快捷方式

桌面快捷方式分为两类,Desktop区,指随着屏幕滚动的那部分,HotSeat区,指放置于桌面底部不随屏幕滚动的部分。用户自定义的HotSeat区里的快捷方式属于常用的应用。如果能够在锁屏界面也添加这部分的快捷启动,会是一个比较友好的功能。这个的主要问题是,怎么获取到HotSeat区的快捷方式呢。

系统快捷方式存储在数据库文件launcher.db中的favorites表中,如图所示:

 

 可以看到有对应的快捷方式的id,title和intent,这个container属性是用来指示所在文件夹的id,然而可以看到有的container为负数。这是为什么,笔者查看了一下Android Launcher相关的源码,找到这么两句: 

  1. /** 
  2. * The icon is a resource identified by a package name and an integer id. 
  3. */ 
  4. public static final int CONTAINER_DESKTOP = -100; 
  5. public static final int CONTAINER_HOTSEAT = -101;  

也就是说,container为-100的是Desktop区的快捷方式,container为-101的正是要找的HotSeat区的快捷方式。

现在知道了快捷方式的存储方式,接下来的问题就是去找launcher.db文件的路径。

在不同版本的Android原生api中,由于默认使用的launcher启动器的包名不一样,launcher.db存储的路径也不一样。

  1. Android API 7及以下:/data/data/com.android.launcher/databases/laucher.db 
  2. Android API 8~18:/data/data/com.android.launcher2/databases/laucher.db 
  3. Android API 19及以上:/data/data/com.android.launcher3/databases/laucher.db  

而对于各式各样的第三方ROM,使用了千奇百怪的laucher包名,这个路径就更乱了: 

  1. HTC: /data/data/com.htc.launcher/databases/laucher.db 
  2. 360: /data/data/net.qihoo360.launcher/databases/laucher.db 
  3. 华为: /data/data/com.huawei.launcher3/databases/laucher.db 
  4. 小米: /data/data/com.miui.mihome2/databases/laucher.db 
  5. ... 

当然,我们不会通过直接读取数据库的方式来获取快捷方式的信息,系统自带的laucher会提供ContentProvider给外部读取。避开了对数据库路径做兼容的大坑,转眼就掉进了另一个大坑,通过Provider来读取快捷方式,所需要的权限和URI也需要做兼容。

从快捷方式的存储可见,Android 的碎片化是多么的严重,所以最后笔者决定不再深入去兼容实现,这是得不偿失的行为,有兴趣实现的可以看看这篇文章,判断一个快捷方式是否存在是多么的难:http://www.jianshu.com/p/dc3d...

3.获取壁纸

锁屏界面的背景和手机桌面壁纸保持一致,不至于让用户觉得突兀,这里有两种办法实现获取壁纸。

Activity Style模式

如果是Activity实现的锁屏界面,可以直接设置Activity的theme就可以用壁纸做背景了。

  1. android:theme="@android:style/Theme.Wallpaper.NoTitleBar" 

WallPaperManager模式

悬浮窗模式的锁屏界面无法用theme,那么可以通过WallPaperManager来获取壁纸。

  1. // 获取壁纸管理器 
  2. WallpaperManager wallpaperManager = WallpaperManager 
  3.                 .getInstance(this); 
  4. // 获取当前壁纸 
  5. Drawable wallpaperDrawable = wallpaperManager.getDrawable(); 
  6. // 将Drawable,转成Bitmap 
  7. Bitmap bm = ((BitmapDrawable) wallpaperDrawable).getBitmap(); 
  8. mRootView.setBackgroundDrawable(new BitmapDrawable(bm)); 

这种方式在小米等仿iOS的一屏桌面上是OK的,但是在原生Android那样的两屏桌面(快捷方式与全部app分别在不同屏),快捷方式那屏获取的壁纸是一整张大壁纸,而实际laucher显示的是切割后的壁纸。所以以上方式会把尺寸不符的壁纸设为了背景。需要自己去根据laucher的屏数和当前是第几屏来进行切图,laucher的总屏数可以在上述launcher.db里的workspaceScreens表里找到,而具体当前在第几屏是存在launcher app内存实例中的,无法获取。如果真要切的话,建议直接按照屏幕宽高切下整张壁纸的左边一屏就好了。

责任编辑:庞桂玉 来源: segmentfault
相关推荐

2016-01-29 10:19:26

2022-10-21 09:01:33

小组件iOS

2014-09-25 09:51:29

Android App个人博客

2020-07-30 09:35:09

Redis分布式锁数据库

2022-01-17 09:22:42

SwiftUI App Store开源

2022-04-14 07:56:30

公平锁Java线程

2021-09-08 15:43:03

在线写作协作文档办公软件

2021-11-01 12:25:56

Redis分布式

2013-12-19 13:25:40

InnoDB数据库

2022-06-16 15:07:06

布局结构app

2017-02-24 10:30:51

iOS开源App Store

2022-03-04 14:17:08

JS工具库录音

2014-07-02 10:03:42

App推广渠道

2014-10-14 15:50:19

UIAndroid

2009-10-20 14:10:00

CCIE经验

2020-12-21 16:35:51

JavaScript网页截屏代码

2012-12-24 13:25:59

微信App

2014-10-14 10:01:10

UIAndroid

2022-09-22 13:28:34

Redis分布式锁

2022-09-29 08:28:57

SpringRedis分布式
点赞
收藏

51CTO技术栈公众号