Android sdk lock screen

Creating a Lock Screen Device App for Android

Android SDK offers to developers a specific API, the Device Administration API, letting their users to lock the device screen directly inside an application. This feature can be interesting for some specific applications. In that tutorial, you are learning to create a Lock Screen Device App for Android using this feature.

Note that you can also discover this tutorial in video on YouTube :

Creating a dedicated XML Policy file

The Device Administration API demands the definition of a dedicated security policies file to declare which policies of the API your application will use. Our Lock Screen Device App will just use the “force-lock” policy letting us to lock the screen of the device immediately.

For that, we create a policies.xml file placed in res/xml of our Android Application Project :

Declaring the use of the Device Administration API

Next step is to declare the use of the Device Administration API in the Android Manifest of our application. To use this dedicated API, the Android Manifest must include the following :

• A subclass of DeviceAdminReceiver including the BIND_DEVICE_ADMINpermission and the ability to respond to the ACTION_DEVICE_ADMIN_ENABLED intent, expressed in the manifest as an intent filter
• A declaration of security policies used in metadata

It gives us the following code for our AndroidManifest.xml file :

Creating a subclass of DeviceAdminReceiver

In the Android Manifest, you have probably noted the presence of a MyAdminclass declared as receiver of the BIND_DEVICE_ADMIN permission. The MyAdmin class is a subclass of the DeviceAdminReceiver class part of the Android SDK.

By subclassing the DeviceAdminReceiver class, we override onEnabled and onDisabled methods. It will let us to react when our security policies will be enabled or disabled by the user within our Lock Screen Device App.

In our MyAdmin class, we just display Toast messages alerting the user :

Creating the User Interface

For our Lock Screen Device App, the User Interface will be quite simple with just three buttons inside a RelativeLayout view :

• A Lock button to lock the device immediately
• An Enable button to enable our security policies
• A Disable button to disable our security policies

It will have the following form :

Writing the Java code of the Main Activity

Now, it’s time to write the Java code of the Main Activity. In the onCreate method, we will get the references of the buttons and we will define the OnClickListener implementation used to manage the users’ clicks on them.

Then, we get the DevicePolicyManager system service and we create a ComponentName instance with our MyAdmin class in parameter. It will let us to check if the security policies associated to that class in the metadata are active or no for our application.

It is done by calling the isAdminActive method of the DevicePolicyManager system service instance got previously with this ComponentName instance. This call is made in the onResume method of our MainActivity.

According to the return of this call, we update the visibility of the enable and disable buttons :

Like our MainActivity implements the OnClickListener interface, we can manage the click on the buttons in the onClick method which is overrided.

When a user click on the lock button, we check if the security policies associated to our MyAdmin class are active or no. If yes, we can lock the screen immediately by calling the lockNow method of the DevicePolicyManager system service. Otherwise, we display a Toast to the user indicating him he must enable the feature.

When a user click on the enable button, we create an Intent with the DevicePolicyManager.ACTION_ADD_DEVICE_ADMIN in parameter. We put some extras like the ComponentName instance created previously and some explanations for the user. Then, we start this activity and we wait for the result. For that, we call the startActivityForResult method with the Intent in parameter.

When a user click on the disable button, we remove our security policies by passing our ComponentName instance in parameter of the removeActiveAdmin on the DevicePolicyManager object instance. And we don’t forget to manage the visibility of the enable / disable buttons too :

Finally, ne need to override the onActivityResult method to handle the result of the starting of the activity to enable the admin features. We check if the resultCode is equal to Activity.RESULT_OK. If yes, we display a message to the user to tell him the Admin Device features have been enabled. Otherwise, we display a message to tell him the Admin Device features have been disabled.

It gives us the following code for the MainActivity :

Testing our Lock Screen Device App

It is the best part of our tutorial since we are going to test our Lock Screen Device Application. When you launch the application, you should see the following screen :

Click on the lock button and you should see the following message on the screen :

So, you need to enable the Admin Device Features. Click on the enable button for that. You should see the following screen to enable the Admin Device Features :

Like you can see, our Lock Screen Device App will just allow to lock the screen immediately. Click on activate and you should see the following screen :

The Device Admin Features have been enabled. Now, you can click on the lock button and the device will be locked immediately.

That’s all for that tutorial ! You can find the complete source code on GitHub : https://github.com/ssaurel/LockScreenDevice

To discover more tutorials on Android development, you can subscribe to the SSaurel’s Channel :

Источник

Как я писал кастомный локер

Привет хабрастарожилам от хабрановичка. Ровно год назад я решил написать кастомный локер (экран блокировки) для моего старичка Samsung Galaxy Gio в стиле популярного тогда Samsung Galaxy s3. Какие причины заставили меня это сделать, писать не буду, но добавлю лишь то, что в Google Play я программу не собирался выкладывать и каким-либо другим способом заработать на ней не планировал. Данный пост посвящен последствиям моего решения.

Начну издалека. Многие хвалят Android за открытость и возможность заменить и настроить встроенные программы под свои нужды. Что тут сказать? В сравнении с другими популярными ОС, это, безусловно, так, но если копнуть глубже в архитектуру Android возникают трудности и вопросы. Локскрин (в Android это называется keyguard) как раз и вызывает вопросы: почему Google не поступили с ним, так как с лаунчерами, почему не сделали диалог со всеми доступными на устройстве локерами и с возможностью выбрать нужный по умолчанию? Где-то в глубине мозга тихим нерешительным голосом кто-то отвечает: может быть Google (Android Ink. если быть точнее) поступил так из соображений безопасности. Этот голос вероятно прав и многим разработчикам локеров и мне (скромность не позволила приписать себя к их числу) пришлось изобретать велосипед, и не один.

Изучаем исходники

Начал я с использования одного из плюсов Android – из изучения исходников. Я один из тех консерваторов, которые уже 2,5 года сидят на стоковой прошивке (2.3.6), поэтому и исходники изучал соответствующие. Классы, отвечающие за блокировку экрана, лежат в android.policy.jar, что в system/framework. Первоначальной целью было найти «точку входа», т.е. где и когда вызывается локер. Искал здесь.

В классе PhoneWindowManager.java есть метод screenTurnedOff(int why), который вызывает одноименный метод класса KeyguardViewMediator. Проследив, кто кого вызывает, я нашел метод в классе KeyguardViewManager, создающий непосредственно View стокового локера.

Что ж, все гениальное – просто. Решил повторить этот код для своего приложения и получил ошибку – нет нужного permission. Немного погуглив, добавил следующие разрешения: SYSTEM_ALERT_WINDOW и INTERNAL_SYSTEM_WINDOW. Это не помогло.

Вернулся к изучению класса PhoneWindowManager.java:

Для требуемого окна TYPE_KEYGUARD нужно второе из моих добавленных разрешений. Задней точкой тела начал ощущать, что не все так просто, как я себе представлял. Решено было посмотреть на описание этого permission. Вот выдержка из AndroidManifest.xml пакета framework-res.apk.

Вот она – черная полоса в жизни. Ведь я понимал, «signature» – это значит, что использовать этот пермишн может только пакет, подписанный тем же ключом, что и пакет, выдавший это разрешение (в нашем случае — framework-res.apk). Ладно, достаем инструменты для изготовления велосипедов.

Версия один

Первым решением было использовать activity в качестве локскрина. На stackoverflow советуют использовать следующий код:

Признаюсь, в первых версиях я использовал этот метод. У него есть существенные недостатки: статусбар не блокируется, начиная с версии API11 этот метод не работает.

Решение первого недостатка (переполнениестека опять помогло) следующее. Поверх статусбара с помощью WindowManager рисуется прозрачный View, который перехватывает все TouchEvent. Вот служба, реализующая это:

Второго недостатка для меня не существовало, на Gingerbread данный код работал превосходно. На 4pda, куда я опрометчиво выложил свое творение, пользователи жаловались, что на многих телефонах мой локер сворачивался как обычное приложение. Для них найдено такое решение. В качестве стандартного лаунчера устанавливается пустышка. При нажатии кнопки HOME система вызывает мой лаунчер-пустышку. Если кастомный локер активен, лаунчер сразу же закрывается в методе onCreate(), т.е. визуально нажатие кнопки HOME ни к чему не приводит. Если кастомный локер не активен, мой лаунчер тут же вызывает другой правильный лаунчер, который пользователь указал в настройках.

Вот код пустышки:

Выглядело это следующим образом:

Эти велосипеды ездили долго и хорошо, пока я не решил сделать «правильный» локскрин, и уже в стиле Samsung Galaxy S4.

Версия два

Когда системе необходимо запускать кастомный локер? Очевидно, что при выключении экрана. Создадим службу, регистрирующую BroadcastReceiver, т.к. из манифеста данный фильтр не работает.

Необходимо учесть две особенности:

1. Служба должна быть запущена в момент загрузки устройства. Создадим BroadcastReseiver с IntentFilter «android.intent.action.BOOT_COMPLETED». Есть одно НО: служба при запуске должна отключить стандартную блокировку экрана. Особенностью Android является то, что стандартное окно ввода PIN-кода является частью стокового экрана блокировки. Поэтому служба должна запускаться только когда PIN буден введен.

Максимум, на что хватило моей фантазии:

2. Проанализировав PhoneWindowManager видно, что в метод screenTurnedOff(int why) передается переменная why, принимающая 3 значения:
— экран выключился по истечению таймаута (в этом случае стоковый локер запускается с задержкой),
— экран выключился при срабатывании сенсора приближения (во время телефонного разговора),
— экран выключился при нажатии кнопки.
В моем случае такого разнообразия нет. Поэтому служба мониторит состояние телефона, и при входящем звонке или во время разговора экран не блокируется.

Вот основной код службы:

Идея не использовать activity, а использовать WindowManager была еще сильна. Из пяти типов окон, использующих разрешение SYSTEM_ALERT_WINDOW, мне подошел TYPE_SYSTEM_ALERT. Причем у него были очевидные достоинства: блокировался статусбар (по крайней мере, на Gingerbread) и перехватывалось нажатие кнопки HOME (работает даже на Jelly Bean).

Промежуточным звеном между службой и KeyguardView является класс KeyguardMediator:

Дальше история становится менее интересной, так сказать, будничной. На мой локер можно добавлять ярлыки приложений (здесь все стандартно и просто) и виджеты (а вот этот момент достоин отдельной статьи).

Теперь все стало выглядеть современней:

Источник

Creating a Lock Screen Device App for Android

Jun 7, 2018 · 5 min read

Android SDK offers to developers a specific API, the Device Administration API, letting their users to lock the device screen directly inside an application. This feature can be interesting for some specific applications. In that tutorial, you are learning to create a Lock Screen Device App for Android using this feature.

Note that you can also discover this tutorial in video on YouTube :

Creating a dedicated XML Policy file

The Device Administration API demand s the definition of a dedicated security policies file to declare which policies of the API your application will use. Our Lock Screen Device App will just use the “force-lock” policy letting us to lock the screen of the device immediately.

For that, we create a policies.xml file placed in res/xml of our Android Application Project :

Declaring the use of the Device Administration API

Next step is to declare the use of the Device Administration API in the Android Manifest of our application. To use this dedicated API, the Android Manifest must include the following :

• A subclass of DeviceAdminReceiver including the BIND_DEVICE_ADMIN permission and the ability to respond to the ACTION_DEVICE_ADMIN_ENABLED intent, expressed in the manifest as an intent filter
• A declaration of security policies used in metadata

It gives us the following code for our AndroidManifest.xml file :

Creating a subclass of DeviceAdminReceiver

In the Android Manifest, you have probably noted the presence of a MyAdmin class declared as receiver of the BIND_DEVICE_ADMIN permission. The MyAdmin class is a subclass of the DeviceAdminReceiver class part of the Android SDK.

By subclassing the DeviceAdminReceiver class, we override onEnabled and onDisabled methods. It will let us to react when our security policies will be enabled or disabled by the user within our Lock Screen Device App.

In our MyAdmin class, we just display Toast messages alerting the user :

Creating the User Interface

For our Lock Screen Device App, the User Interface will be quite simple with just three buttons inside a RelativeLayout view :

• A Lock button to lock the device immediately
• An Enable button to enable our security policies
• A Disable button to disable our security policies

It will have the following form :

Writing the Java code of the Main Activity

Now, it’s time to write the Java code of the Main Activity. In the onCreate method, we will get the references of the buttons and we will define the OnClickListener implementation used to manage the users’ clicks on them.

Then, we get the DevicePolicyManager system service and we create a ComponentName instance with our MyAdmin class in parameter. It will let us to check if the security policies associated to that class in the metadata are active or no for our application.

It is done by calling the isAdminActive method of the DevicePolicyManager system service instance got previously with this ComponentName instance. This call is made in the onResume method of our MainActivity.

According to the return of this call, we update the visibility of the enable and disable buttons :

Like our MainActivity implements the OnClickListener interface, we can manage the click on the buttons in the onClick method which is overrided.

When a user click on the lock button, we check if the security policies associated to our MyAdmin class are active or no. If yes, we can lock the screen immediately by calling the lockNow method of the DevicePolicyManager system service. Otherwise, we display a Toast to the user indicating him he must enable the feature.

When a user click on the enable button, we create an Intent with the DevicePolicyManager.ACTION_ADD_DEVICE_ADMIN in parameter. We put some extras like the ComponentName instance created previously and some explanations for the user. Then, we start this activity and we wait for the result. For that, we call the startActivityForResult method with the Intent in parameter.

When a user click on the disable button, we remove our security policies by passing our ComponentName instance in parameter of the removeActiveAdmin on the DevicePolicyManager object instance. And we don’t forget to manage the visibility of the enable / disable buttons too :

Finally, ne need to override the onActivityResult method to handle the result of the starting of the activity to enable the admin features. We check if the resultCode is equal to Activity.RESULT_OK. If yes, we display a message to the user to tell him the Admin Device features have been enabled. Otherwise, we display a message to tell him the Admin Device features have been disabled.

It gives us the following code for the MainActivity :

Testing our Lock Screen Device App

It is the best part of our tutorial since we are going to test our Lock Screen Device Application. When you launch the application, you should see the following screen :

Click on the lock button and you should see the following message on the screen :

So, you need to enable the Admin Device Features. Click on the enable button for that. You should see the following screen to enable the Admin Device Features :

Like you can see, our Lock Screen Device App will just allow to lock the screen immediately. Click on activate and you should see the following screen :

The Device Admin Features have been enabled. Now, you can click on the lock button and the device will be locked immediately.

That’s all for that tutorial ! You can find the complete source code on GitHub :

Источник