Android studio экран блокировки

Создание приложения Android Lock Screen.

Как создать приложение блокировки экрана, которое действует как блокировка для мобильного телефона Android. Я нашел один, но это был плохо построенный код, и если бы я нажал физический домашний ключ, он разблокировался, делая приложение бессмысленным.

Я столкнулся с форумом, в котором говорится о том, что в Android 4.x был удален какой-то способ блокировки функции кнопки «домой»

Тем не менее, у меня есть потрясающая идея для блокировки экрана, но нет оснований для начала. Если у кого-нибудь есть какие-либо знания по этому вопросу, я бы с удовольствием это услышал.

Да, это возможно. Это простой исходный код блокировки экрана от GitHub

Создание приложения, которое работает как блокировка, не имеет большого значения, но, как вы сказали, для ключевого вопроса Home, я бы предложил вам продолжать и разрабатывать приложение столько, сколько вам нужно, и единственная конечная область, которую вы застряли, – это управление домашним ключом Поэтому попробуйте найти какой-нибудь сложный способ получить контроль над домашним ключом и сделать его как приложение для вашего приложения блокировки. Это не очень сложно, но любопытно сложно. Я отправлю вам сообщение, если я найду исходные коды доступа к домашнему ключу

PS:

Вот учебник по доступу к Home Key

Я где-то нашел ключ дома. Добавьте эти строки в манифест приложения.

Следуя двум строкам, волшебство

И переопределить этот метод в вашей деятельности

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

PS: на основе голосов я могу гарантировать, что мое предложение работает, и вы можете разработать такое приложение с помощью вышеупомянутой справки 🙂

Источник

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

Привет хабрастарожилам от хабрановичка. Ровно год назад я решил написать кастомный локер (экран блокировки) для моего старичка 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:

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

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

Источник

Android programmers blog

Simply about difficult

Поиск по этому блогу

вторник, 24 декабря 2013 г.

Создание экрана блокировки для Android

Всем привет, сегодня я хотел бы рассказать вам как делать экран блокировки для Android, я думаю многие задумывались как это делается, оказывается что не сильно то и сложно. (: Всего лишь нужно создать сервис, бродкаст ресивер и активность которая это будет отображать. Звучит конечно устрашающе но на самом деле все намного проще.
И так приступим, для начала мы создадим разметку в которой у нас будет два объекта (две картинки), первая будет объектом который будет перетаскиваться, а второй объектом на который будут перетаскивать что бы разблокировать экран, ну и еще у нас будут часы которые будут показывать время, но это не сильно важный элемент. (:

Выглядеть все в купе буде вот так:

Что у нас там такое в этой разметке, внутри RelativeLayout у нас два LinearLayout которые хранят два разных объекта, в первом у нас объект который будет перемещаться по экрану, а во втором статичный объект, это мы сделали что бы при перемещении яблока дроид у нас не перемещался вместе с яблоком.

Собственно тут у нас имеется два ImageView и TextView, пока вроде бы все просто и понятно, продолжим.

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

Из комментариев ясно что тут мы проверяем флаг состояния телефона, и при помощи метода .filter() проверяем флаг ACTION_SCREEN_OFF который присылает или true или false соответственно. По изменению true для этого флага у нас запускается Broadcast Receiver.

BroadcastReceiver — это объект, который начинает выполнять действия, по получению какого нибудь сигнала (Intent). Service в отличии от BroadcastReciever работает сразу после того как его запустили.

Но для начала мы создадим активность которая будет запускать наш сервис при старте программы. Как вы читали выше сервис работает постоянно, соответственно если вы запустили его раз и не выключили то он будет работать до самого удаления программы.

Тут все просто, при старте программы у нас изначально запускается этот класс и начинается отслеживание состояния телефона. Она запускается первой как скрытая активность, это вы увидите в самом конце когда я покажу вам AndroidManifest.

Теперь нам нужен Broadcast Receiver так как без него ничего не будет происходить. Выглядит он вот так:

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

Это самый большой класс во всем проекте, в нем мы инициализируем все переменные, обрабатываем все касания к экрану, собственно все что должно происходить на экране для нашего приложения.

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

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

Я постарался прокомментировать каждую строчку кода, надеюсь что сильно детального описания не нужно.

Осталось только немного изменить наш AndroidManifest, в нем мы добавим наши активности, так же определим когда запускать BroadcastReceiver и Service. И нужно не забыть про разрешения для девайса на запуск всего этого зоопарка классов.

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

Да я забыл сказать что, что бы разблокировать нада провести яблоко к андроиду, и тогда разблокируется экран, а то мало ли, не хочется что бы потом люди кричали что заблокировали экран и не смогли разблокировать и пришлось перепрошивать телефон (:

Источник

Экран

Небольшая подборка различных примеров для работы с экраном. На самом деле их не так часто приходится использовать в практике, но иметь общее представление бывает необходимым. Начало было положено в 2012 году, что-то могло устареть.

Настройки — Экран

Чтобы показать окно Экран из системного приложения Настройки:

Размеры экрана и его ориентация (Старый и новый способ)

Чтобы узнать размеры экрана и его ориентацию из запущенного приложения, можно воспользоваться встроенными классами Android.

Данный способ был опубликован в те времена, когда у меня был Android 2.3. Читатели подсказали, что теперь методы считаются устаревшими (API 13 и выше). Пришлось переписывать код. Впрочем, спустя некоторое время и этот код стал считаться устаревшим.

Ориентацию при помощи нового метода не узнаешь. Помните, что это размеры экрана устройства, а не экрана вашего приложения. Кроме того, в документации как-то туманно описывается точность вычислений этих размеров. Никому верить нельзя.

Плотность экрана, масштабирование шрифта и др.

Существует класс DisplayMetrics, также имеющий в своём составе свойства для экрана. Пример также пришлось переписывать после выхода Android 11 (API 30), который теперь тоже устаревший:

Вот ещё несколько способов определения размеров:

Такой же код, но с использованием дополнительной константы SCREENLAYOUT_SIZE_MASK:

На Kotlin в виде отдельной функции.

Заглянув в документацию, обнаружил, что можно обойтись без собственных констант. Они уже есть в Android. Оформил в виде отдельного метода.

Получить текущее значение яркости экрана

В настройках экрана можно установить желаемую яркость экрана при помощи ползунка, но при этом мы не знаем, сколько это в попугаях. Я открою вам секрет при помощи простого кода:

Установить яркость экрана

Если можно получить значение текущей яркости экрана, значит можно и установить яркость. Для начала нужно установить разрешение на изменение настроек в манифесте:

Для настройки яркости нужно использовать параметр System.SCREEN_BRIGHTNESS. Добавим на форму кнопку, метку и ползунок. Код для установки яркости:

Проверил старый пример времён Android 2.2 на эмуляторе с Android 10. Правила ужесточились. Теперь разрешение на изменение системных настроек выдаются только системным программам. Пока ещё есть лазейка, которой и воспользуемся. Новый пример написан на Kotlin. Добавим в манифест немного модифицированное разрешение.

Далее программа должна проверить возможность изменять системные настройки через метод canWrite(). Если такая возможность есть, то запрашиваем разрешение. Появится специальное окно, в котором пользователь должен подтвердить своё решение через переключатель. После этого нужно заново запустить программу, чтобы ползунок стал доступен. Теперь можете менять настройки.

Настраиваем яркость экрана в своём приложении

Существует возможность переопределить яркость экрана в пределах своего приложения. Я не смог придумать, где можно найти практическое применение, но вдруг вам пригодится. Для управления яркостью экрана воспользуемся элементом SeekBar.

За яркость экрана отвечает свойство LayoutParams.screenBrightness:

Интересно, что когда выводил ползунок в значение 0, то эмулятор зависал с экраном блокировки. Вам следует учесть эту ситуацию и добавить условие:

Опять столкнулся с проблемой. Пример работал на старых устройствах, а на некоторых устройства не работает. Но за эти годы мне ни разу не пришлось использовать этот способ, поэтому даже не стал искать причину. И кстати, ошибка со значением 0 уже не возникает (возможно из-за того, что сам пример не работает как раньше).

Определение поддерживаемых экранных размеров в манифесте

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

В данном примере приводится поддержка нормальных и больших экранов. Маленьким экраном можно назвать любой дисплей с разрешением меньше, чем HVGA. Под большим экраном подразумевается такой, который значительно больше, чем у смартфона (например, у планшетов). Экран нормальных размеров имеет большинство смартфонов.

Атрибут anyDensity говорит о том, каким образом ваше приложение будет масштабироваться при отображении на устройствах с разной плотностью пикселов. Если вы учитываете это свойство экрана в своем интерфейсе, установите этому атрибуту значение true. При значении false Android будет использовать режим совместимости, пытаясь корректно масштабировать пользовательский интерфейс приложения. Как правило, это снижает качество изображения и приводит к артефактам при масштабировании. Для приложений, собранных с помощью SDK с API level 4 и выше, этот атрибут по умолчанию имеет значение true.

Размеры картинок для фона экрана

Если вы используете изображение в качестве фона, то нет смысла выводить очень большую картинку на устройстве с маленьким экраном. Можно подготовить разные размеры.

res/drawable-ldpi — 240×320
res/drawable-mdpi — 320×480
res/drawable-hdpi — 480×800
res/drawable-xhdpi — 640×960
res/drawable-xxhdpi — 960×1440
res/drawable-tvdpi — 1.33 * mdpi

Источник