- Взаимодействие Android-устройств в локальной сети
- О чем это и для кого это?
- Какие возможные способы решения существуют?
- Wi-Fi и много других аббревиатур. Как в Android приложении получить данные об узлах Wi-Fi и не опухнуть
- 1. Создаем проект
- 2. Разрешения на доступы
- 3. Создаем BroadcastReceiver и подписываемся на события обновления данных о сканировании сетевого окружения Wi-Fi
- 4. Смотрим на ScanResult и разбираемся в терминах
- 5. Разбираемся в аббревиатурах и парсим capabilities
- 6. Создаем модель и функцию парсинга
- 8. Смотрим результат
- Отвязываем смартфон от всевидящего ока Google
- Введение
- Что такое Google Apps
- Способ номер 1. Отключение через настройки
- Хакер #182. Все о Bitcoin
- Способ номер 2. Очистка официальной прошивки
- Способ номер 3. Кастомная прошивка без gapps
- Способ номер 4. Google Play и ничего кроме
- Меняем поисковик на DuckDuckGo
- Сторонний маркет
- Open Source Маркет
- Решение проблемы зависимости приложений от Google Apps
- Выводы
- Евгений Зобнин
Взаимодействие Android-устройств в локальной сети
Предположим, мы пишем игру для Android, которая подразумевает некое сетевое взаимодействие между устройствами. Причем наши устройства находятся в одной сети и мы хотим, чтобы взаимодействие между ними осуществлялось быстро, а значит вариант с обменом данными через интернет нам не подходит. Ах да, еще одна маленькая ложка дегтя — мы хотим охватить максимально возможную аудиторию, для чего нам необходимо поддерживать Android 2.3.
Что же нам делать? Давайте поговорим об этом, а заодно рассмотрим относительно новые возможности Android SDK для соединения двух и более устройств.
О чем это и для кого это?
Как-то раз, уйдя с предыдущего места работы и погрузившись в заслуженный отдых, я принялся писать сетевую игру, в которую могут играть люди, находящиеся в одной локальной сети. И сразу же столкнулся с тем, что для нормального функционирования подобной игры нам мало соорудить сетевое взаимодействие — нам нужно сделать нормальное и быстрое обнаружение устройств в сети. Собственно, в данной статье я поделюсь своим опытом в реализации решения для данной задачи.
Сразу оговорюсь, что статья предназначена в большей мере для тех, кто имеет опыт Android-разработки, написал несколько приложений и хочет расширить свой кругозор, а также улучшить профессиональные навыки.
Какие возможные способы решения существуют?
- Android Network Service Discovery. Простой и эффективный способ обнаружения устройств. На Android Developer есть пошаговое руководство по подключению NSD, есть пример NsdChat, который можно скачать там же. Но есть один существенный минус — данный метод поддерживается только начиная с API Level 16, то есть с Android 4.1 Jelly Bean;
- Второе решение, предлагаемое нам на сайте Android Developer — Wi-Fi Peer-to-Peer. Проблема этого метода та же самая — поддерживается он только начиная с API Level 16;
- Есть странное решение, которое предлагается некоторыми программистами на Stack Overflow — самостоятельно сканировать локальную сеть на предмет наличия сервера. То есть проходить по всем адресам сети. Это уже сейчас звучит как странный велосипед, а теперь представьте, что порт нашего сервера назначается автоматически. Таким образом, сканирование даже самую небольшой сети становится достаточно долгой и трудоемкой задачей;
- Наконец, мы можем обратить внимание на Java-библиотеки и написать что-нибудь с их использованием. Например, JmDNS.
Последний способ выглядит вполне адекватным и, кажется, может обеспечить нас требуемой скоростью и удобством обнаружения устройств в сети для конечного пользователя.
Я вооружился JmDNS и решил попробовать соорудить несколько классов, которые по максимуму упростят написание описанных выше приложений. Но для начала пришлось немного повырезать дубликаты .class-файлов из jar-пакета JmDNS (проблема описана здесь):
Далее я взял исходный код NsdChat с Android Developer и изменил его служебный класс, который отвечает за инициализацию сокетов и организацию сетевого взаимодействия. Также я написал wrapper для JmDNS
Здесь размещены 4 основные функции для работы Network Discovery:
- startServer для создания сервера и регистрации соответствующего сервиса в локальной сети;
- findServers для поиска серверов;
- reset для окончания работы с Network Discovery и последующего освобождения ресурсов;
- wifiLock для запроса блокировки Wi-Fi.
В завершении я написал универсальный класс ConnectionWrapper для полноценной организации обнаружения, а также обмена сообщениями в локальной сети. Таким образом, создание сервера в конечном приложении выглядит следующим образом:
А вот и mServerHandler, использующийся для приема и обработки сообщений:
Отправка сообщений еще проще:
И, наконец, метод для обнаружения и подключения к серверу:
Как видите, все очень просто. А главное, все это работает в любой версии Android для максимум двух устройств. Но сделать так, чтобы это работало для условно неограниченного числа устройств очень легко, и очевидное решение придет к вам почти сразу после детального изучения класса Connection. Пусть это будет в качестве домашнего задания.
Ах, да, весь код доступен для изучения и использования всеми желающими в моем репозитории на GitHub.. И, конечно, не исключаю то, что некоторые вещи можно сделать лучше и проще, поэтому не стесняйтесь форкать и делать pull request’ы.
Источник
Wi-Fi и много других аббревиатур. Как в Android приложении получить данные об узлах Wi-Fi и не опухнуть
Однажды мне понадобилось сканировать из Android приложения сети Wi-Fi и получать подробную выкладку данных о точках доступа.
Тут пришлось столкнуться с несколькими трудностями: в офф.документации Android многие описанные классы стали deprecated (API level > 26), что никак не было в ней отражено; описание некоторых вещей в документации минимально (например поле capabilities класса ScanResult на момент написания не описано почти никак, хотя содержит много важных данных). Третья сложность может заключаться в том, что при первой близости с Wi-Fi, отличной от чтения теории и настройки роутера по localhost, приходится иметь дело с рядом аббревиатур, которые кажутся понятными по отдельности. Но может быть не очевидно, как их соотнести и структурировать (суждение субъективно и зависит от предыдущего опыта).
В данной статье рассмотрено как из Android кода получить исчерпывающие данные о Wi-Fi окружении без NDK, хаков, а лишь с помощью Android API и понять, как их интерпретировать.
Не будем тянуть и начнем писать код.
1. Создаем проект
Заметка рассчитана на тех, кто больше одного раза создавал Android проект, поэтому подробности данного пункта опускаем. Код ниже будет представлен на языке Kotlin, minSdkVersion=23.
2. Разрешения на доступы
Для работы с Wi-Fi из приложения понадобится получить от пользователя несколько разрешений. В соответствии с документацией, для того, чтобы осуществить сканирование сети на устройствах с ОС версий после 8.0, помимо доступа к просмотру состояния сетевого окружения нужен либо доступ на изменение состояния модуля Wi-Fi устройства, либо доступ к координатам (примерным или точным). Начиная с версии 9.0 необходимо запросить у пользователя и то и то, и при этом явно запросить у пользователя включить службу определения местоположения. Не забываем галантно объяснять пользователю, что это прихоть компании Google, а не наше желание устроить за ним слежку 🙂
Итого, в AndroidManifest.xml добавим:
А в коде, в котором есть ссылка на текущую Activity:
3. Создаем BroadcastReceiver и подписываемся на события обновления данных о сканировании сетевого окружения Wi-Fi
Метод WiFiManager.startScan в документации помечен как depricated с версии API 28, но офф. guide предлагает использовать его.
Итого, получили список объектов ScanResult.
4. Смотрим на ScanResult и разбираемся в терминах
Посмотрим на некоторые поля этого класса и опишем, что они означают:
SSID — Service Set Identifier – это название сети
BSSID – Basic Service Set Identifier – MAC адрес сетевого адаптера (Wi-Fi точки)
level — Received Signal Strength Indicator [dBm (русское дБм) — Децибел, опорная мощность 1 мВт.] — Показатель уровня принимаемого сигнала. Принимает значение от 0 до -100, чем дальше от 0, тем больше мощности сигнала потерялось по пути от Wi-Fi точки к вашему устройству. Подробнее можно посмотреть например на Википедии. Здесь же расскажу, что с помощью Android класса WifiManager можно проградуировать уровень сигнала по шкале от отличного до ужасного с выбранным вами шагом:
frequency — частота работы точки Wi-Fi [Гц]. Помимо самой частоты вас может заинтересовать так называемый канал. У каждой точки есть своя рабочая чистота. На момент написания текста наиболее популярным диапозоном Wi-Fi точек является 2.4 GHz. Но, если быть точнее, точка передает информацию на ваш телефон на пронумерованной частоте, близкой к названной. Количество каналов и значения соответствующих частот стандартизованы. Это сделано для того, чтобы точки поблизости работали на разных частотах, тем самым не создавая помехи друг другу и взаимно не понижая скорость и качество передачи. При этом точки работают не на одной частоте, а на диапазоне частот (пареметр channelWidth), называемом шириной канала. То есть точки, работающие на соседних (и не только на соседних, а даже на 3 от себя) каналах создают друг другу помехи. Вам может пригодится этот незамысловатый код, который позволяет вычислить номер канала по значению частоты для точек с частотой 2.4 и 5 Ghz:
capabilities — наиболее интересное поле для анализа, работа с которым потребовало много времени. Тут в строку записываются «возможности» точки. При этом подробности интерпритации строки в документации можно не искать. Вот несколько примеров того, что может лежать в этой строке:
5. Разбираемся в аббревиатурах и парсим capabilities
Стоит упомянуть, что классы пакета android.net.wifi.* использует под капотом linux-утилиту wpa_supplicant и результат вывода в поле capabilities является копией поля flags при сканировании.
Будем действовать последовательно. Рассмотрим сначала вывод такого формата, при котором внутри скобок элементы отделены знаком «-«:
Первое значение описывает т.н. метод аутентификации (authentication). То есть, какую последовательность действий должны произвести устройство и точка доступа, чтобы точка доступа позволила собой пользоваться и каким образом шифровать полезную нагрузку. На момент написания поста самые частые варианты это WPA и WPA2, при котором либо каждое подключаемое устройство напрямую, либо через т.н. RADIUS-сервер (WPA-Enterprice) предоставляет пароль по зашифрованному каналу. Скорее всего у вас дома точка доступа предоставляет подключение по этой схеме. Отличие второй версии от первой в болеее стойком шифре: AES против небезопасного TKIP. Также постепенно внедряется WPA3, более сложный и продвинутый. Теоритически может встретиться вариант с enterprice-решением CCKM (Cisco Centralized Key Managment), но мне так и не встретился.
Точка доступа могла быть настроена на аутентификацию по MAC-адресу. Или, если точка доступа предоставляет данные по устаревшему алгоритму WEP, то аутентификации фактически нет (секретный ключ тут и является ключом шифрования). Такие варианты отнесем к типу OTHER.
Ещё есть полюбившийся в общественных wi-fi метод со скрытым Captive Portal Detection — запрос аутентификации через браузер. Такие точки доступа выглядят для сканера как открытые (какими с точки зраения физического подключения и являются). Поэтому отнесем их к типу OPEN.
Второе значение можно обозначить как алгоритм использования ключей (key management). Является параметром метода аутентификации, о котором написано выше. Говорит о том, как именно происходит обмен ключами шифрования. Рассмотрим возможные варианты. EAP — используется в упомянутом WPA-Enterprice, использует базу данных для сверки введеных аутентификационных данных. SAE — используется в продвинутом WPA3, более устойчива к перебору. PSK — самый частый вариант, подразумевает ввод пароля и его передачу в зашифрованном виде. IEEE8021X — по международному стандарту (отличному от поддержанным семейством WPA). OWE (Opportunistic Wireless Encryption) является расширением стандарта IEEE 802.11, для точек, которые мы отнесли к типу OPEN. OWE обеспечивает безопасность данных, передаваемых по незащищенной сети, за счет их шифрования. Также возможен варинант когда ключей доступа нет, назовем такой вариант NONE.
Третьим параметром является т.н. метод шифрования (encryption schemes) — как именно используется шифр для зашиты передаваемых данных. Перечислим варианты. WEP — использует поточный шифр RC4, секретный ключ является ключом шифрования, что в мире современной криптографии считается неприемлемым. TKIP — используется в WPA, CKIP — в WPA2. TKIP+CKIP — может быть указан в точках умеющих WPA и WPA2 для обратной совместимости.
Вместо трех элементов можно встретить одинокую пометку WEP:
Как мы обсудили выше, этого достаточно чтобы не конкретизировать алгоритм использования ключей, которого нет, и метода шифрования, которое одно по-умолчанию.
Теперь рассмотрим такую скобочку:
Это режим работы Wi-Fi или топология сетей Wi-Fi. Вам может встретиться Режим BSS (Basic Service Set) — когда есть одна точка доступа, через которую общаются подключенные устройства. Можно встретить в локальных сетях. Как правило точки доступа нужны для того, чтобы соединять устройства из разных локальных сетей, поэтому они являются частью Extended Service Sets — ESS. Тип IBSSs (Independent Basic Service Sets) говорит о том, что устройство является частью Peer-to-Peer сети.
Ещё может попасться флаг WPS:
WPS (Wi-Fi Protected Setup) — протокол полуавтоматической инициализации сети Wi-Fi. Для инициализации пользователь либо вводит 8-символьный пароль, либо зажимает кнопку на роутере. Если ваша точка доступа относится к первому типу и этот флажок высветился напротив имени вашей точки доступа, вам настоятельно рекомендуется зайти в админку и отключить доступ по WPS. Дело в том, что часто 8-значный PIN можно узнать по MAC-адресу, либо перебрать за обозримое время, чем кто-то нечистый на руку сможет воспользоваться.
6. Создаем модель и функцию парсинга
На основе того, что выяснили выше опишем data-классами то, что получилось:
Теперь напишем функцию, которая будет парсить поле capabilities:
8. Смотрим результат
Посканирую сеть и покажу, что получилось. Показаны результаты простого вывода через Log.d:
Неосвещенным остался вопрос подключения к сети из кода приложения. Скажу только, что для того, чтобы считать сохраненные пароли ОС мобильного устройства, нужны root-права и готовность порыться в файловой системе чтобы прочитать wpa_supplicant.conf. Если логика приложения предполагает ввод пароля извне, подключение можно осуществить через класс android.net.wifi.WifiManager.
Спасибо Егору Пономареву за ценные дополнения.
Если считаете, что нужно что-то добавить или исправить, пишите в комментарии 🙂
Источник
Отвязываем смартфон от всевидящего ока Google
Компания Google быстро прошла путь от небольшой поисковой системы до гигантской инфраструктуры, компоненты которой работают на наших ПК, смартфонах, планшетах и даже телевизорах. Google неустанно собирает о нас информацию, поисковые запросы тщательно логируются, перемещения отслеживаются, а пароли, письма и контактная информация сохраняются на годы вперед. Все это неотъемлемая часть современности, но мы вполне можем ее изменить.
Введение
Ни для кого не секрет, что любое устройство под управлением Android (по крайней мере то, что сертифицировано Google) содержит в себе не только компоненты, собранные из AOSP, но и внушительное количество проприетарных программ Google. Это те самые Google Play, Gmail, Hangouts, Maps и еще куча приложений, включая диалер и камеру (начиная с KitKat).
Для всех этих компонентов нет не только исходного кода, но и вообще каких-либо пояснений по поводу принципов их работы. Многие из них изначально созданы с целью собирать определенные виды информации и отправлять их на серверы Google. Так, например, ведут себя GoogleBackupTransport, отвечающий за синхронизацию списка установленных приложений, паролей и других данных, GoogleContactsSyncAdapter, который синхронизирует список контактов, или ChromeBookmarksSyncAdapter, работа которого — синхронизировать закладки браузера. Плюс сбор информации обо всех запросах в поисковике.
В самом факте синхронизации, конечно, ничего плохого нет, и это великолепный механизм, который позволяет настроить новый телефон за считаные минуты, а Google Now даже умудряется дать нам полезную информацию на основе наших данных (иногда). Проблема только в том, что все это рушит нашу конфиденциальность, ибо, как показал Сноуден, под колпаком у АНБ (и, вероятнее всего, у кучи других служб) находится не только какая-нибудь империя зла под названием Microsoft, но и Google, а также множество других компаний из тусовки «мы не зло, а пушистые меценаты».
Говоря другими словами: Гугл сольет нас всех без всяких проблем, и не факт, что его сотрудники, сидя в своих офисах с массажистками и собачками, не ржут над именами из твоей контактной книги (там все зашифровано, да), попивая 15-летний пуэр из провинции Юньнань. А может быть, к черту этот Гугл? Возьмем их Android, а сами они пусть идут лесом?
Что такое Google Apps
Последняя версия кастомной прошивки на основе KitKat для моего смартфона весит 200 Мб, однако, чтобы получить настоящий экспириенс от смартфона, я должен прошить поверх нее еще и архив gapps, размер которого составляет 170 Мб. Только после этого я получу систему, аналогичную предустановленной на Nexus-устройства, со всеми плюшками в виде интегрированного с Google Now рабочего стола, блокировку экрана на основе снимка лица, камеру с поддержкой сферической съемки и килограмм гугловского софта, начиная от Google Play и заканчивая Google Books.
Еще раз повторюсь: все это закрытый софт от Google, который по-хорошему вообще нельзя распространять без их ведома (поэтому его нет в кастомных прошивках типа CyanogenMod), но так как извлечь его из прошивок Nexus-девайсов довольно просто, то в Сети можно найти огромное количество подобных архивов, в том числе сильно урезанных. Для того чтобы выпустить смартфон на Android с набором gapps на борту, производитель должен отправить его на сертификацию в Google, которая, оценив качество и производительность смартфона, либо даст добро, либо отфутболит (но китайцев это вообще никак не останавливает).
Так Google Apps попадают на смартфон. Из пользователей 99% либо юзают предустановленные приложения, либо устанавливают их самостоятельно на абсолютно чистую и полностью анонимную прошивку. А дальше с момента ввода имени пользователя и пароля начинается синхронизация и слив информации.
Чтобы разобраться, как это происходит, распакуем тот самый архив с gapps и взглянем внутрь. Нас интересуют каталоги /system/app и /system/priv-app , при установке их содержимое копируется в одноименные каталоги внутри смартфона. Второй каталог — это новшество KitKat, в нем размещаются приложения, использующие системные API, помеченные как «private» и не доступные обычным приложениям.
В каталоге /system/app мы найдем большое количество разных гугловских приложений, легко узнаваемых по названию пакета: Books.apk, Chrome.apk, Gmail2.apk и так далее. Каждое из них по-своему будет делиться информацией, но это абсолютно нормально (да, Google будет знать, что ты читаешь Пауло Коэльо через их приложение!). Наибольшую опасность здесь представляет GoogleContactsSyncAdapter.apk, который отвечает только за то, чтобы отправлять на удаленный сервер список контактов. Записываем название в блокнот и идем дальше.
Большинство файлов из каталога /system/priv-app — это сервисы и фреймворки, необходимые для запуска всей этой махины синхронизации и слежки:
- GoogleBackupTransport.apk — занимается синхронизацией данных установленных приложений, паролей Wi-Fi и некоторых настроек;
- GoogleLoginService.apk — связывает устройство с Google-аккаунтом;
- GooglePartnerSetup.apk — позволяет сторонним приложениям получить доступ к сервисам Google;
- GoogleServicesFramwork.apk — фреймворк с различной подсобной функциональностью;
- Phonesky.apk — Play Store (как ни странно);
- PrebuiltGmsCore.apk — Google Services, как видно из названия, это ядро всего комплекта gapps;
- Velvet.apk — поиск от Google, включающий в себя строку поиска на рабочем столе и Google Now.
В сущности, это и есть та часть Google Apps, которая ответственна за слив нашей частной информации. Попробуем от всего этого избавиться.
Способ номер 1. Отключение через настройки
Самый простой способ отвязать смартфон от Google — это воспользоваться стандартными настройками системы. Метод хорош тем, что не требует ни прав root, ни установки кастомных прошивок, ни кастомного рекавери. Все можно сделать в любой стоковой прошивке без потери доступа к аккаунту и приложениям типа Gmail (если это необходимо). Однако за эффективность никто ручаться не будет, так как вполне возможно, что некоторые компоненты gapps продолжат отправку данных.
Основное место расположения настроек синхронизации — это меню «Настройки -> Аккаунты -> Google -> user@gmail.com». Здесь можно отключить такие вещи, как синхронизация контактов, данных приложений, Gmail, Play Music, Google Keep и прочее. Все, что нужно сделать, — это просто снять галочки с нужных пунктов меню. Далее идем в меню «Настройки -> Восстановление и сброс» и снимаем галки с пунктов «Резервирование данных» и «Автовосстановление».
За множество настроек синхронизации отвечает также приложение «Настройки Google», которое является частью Google Services. С его помощью, в частности, можно отключить доступ Google к местоположению («Доступ к геоданным -> Доступ к моим геоданным / Отправка геоданных / История местоположений»), отключить отправку личных данных поисковику («Поиск -> Личные данные»), отключить Google Now («Поиск -> Google Now») и отключить удаленное управление («Удаленное управление -> Удаленный поиск устройства / Удаленная блокировка и сброс настроек»).
В тех же «Настройках Google», кстати, можно отключить любое приложение, использующее аккаунт Google для авторизации. Речь при этом идет не только о софте, установленном на девайс, но и вообще обо всех когда-либо использованных приложениях, включая веб-сайты. Я, например, обнаружил в этом списке множество сайтов, на которые не заходил уже как минимум пару лет.
В том случае, если ты вообще не собираешься использовать сервисы Google, проще будет отключить смартфон от аккаунта полностью, то есть просто удалить его через настройки: «Настройки -> Аккаунты -> Google -> user@gmail.com -> Кнопка Меню -> Удалить аккаунт».
Хакер #182. Все о Bitcoin
Способ номер 2. Очистка официальной прошивки
В том случае, если на стоковой прошивке есть права root, от Google Apps можно избавиться, просто удалив их со смартфона. Как я уже говорил, все они хранятся в каталогах /system/app и /system/priv-app . Например, в случае с KitKat список Google-приложений в первом каталоге будет таким:
- Books.apk — Google Книги;
- CalendarGoogle.apk — Google Календарь;
- Chrome.apk — Google Chrome;
- CloudPrint.apk — система облачной печати;
- Drive.apk — Google Drive;
- GenieWidget.apk — виджет новостей и погоды;
- Gmail2.apk — Gmail;
- GoogleContactsSyncAdapter.apk — синхронизация контактов;
- GoogleEars.apk — Google Ears (аналог Shazam);
- GoogleEarth.apk — Google Земля;
- GoogleHome.apk — домашний экран с интегрированным Google Now;
- GoogleTTS.apk — система синтеза речи;
- Hangouts.apk — Google Hangouts;
- Keep.apk — Google Keep;
- LatinImeGoogle.apk — клавиатура с поддержкой жестов;
- Magazines.apk — Google Журналы;
- Maps.apk — Google Карты;
- Music2.apk — Google Музыка;
- PlayGames.apk — Google PlayGames;
- PlusOne.apk — Google+;
- QuickOffice.apk — QuickOffice;
- Street.apk — Google Street;
- SunBeam.apk — живые обои SunBeam;
- Videos.apk — Google Фильмы;
- YouTube.apk — YouTube.
В каталоге /system/priv-app , кроме перечисленных ранее, также хранятся такие файлы:
- CalendarProvider.apk — хранит данные календаря;
- GoogleFeedback.apk — отправляет отчет об использовании Google Play;
- GoogleOneTimeInitilalizer.apk — мастер установки дополнительных Google-приложений;
- SetupWizard.apk — мастер настройки при первом запуске;
- Wallet.apk — Google Кошелек;
- talkback.apk — оповещение голосом о событиях на устройстве.
Но это еще не все. Google Apps зависят от нескольких фреймворков, которые находятся в каталоге /system/framework . Это файлы com.google.android.maps.jar, com.google.android.media.effects.jar и com.google.widevine.software.drm.jar. Еще есть множество библиотек в каталоге /system/lib , которые используются исключительно Google-приложениями. Удалять их совсем не обязательно, но можно. Просто чтобы очистить мусор. Их список ты найдешь на сайте ][.
В прошлых (да и в будущих) версиях системы содержимое Google Apps отличается, поэтому перед удалением рекомендую скачать gapps нужной версии с сайта goo.im/gapps, распаковать с помощью WinRar и просмотреть содержимое. Также следует учитывать зависимость некоторых приложений из маркета от приложений Google, подробнее об этом я расскажу позже.
Это только часть библиотек, входящих в комплект gapps
Способ номер 3. Кастомная прошивка без gapps
Предыдущий способ можно существенно упростить, если просто установить на смартфон кастомную прошивку без Google Apps. В этом случае смартфон/планшет будет кристально чист без всякой привязки к Google. Недостаток этого способа — отсутствие Google Play, но можно либо заменить его сторонним магазином приложений (об этом ниже), либо использовать следующий способ, который включает в себя установку урезанной версии Google Apps.
Способ номер 4. Google Play и ничего кроме
Этот способ частичной отвязки от Google — своего рода компромисс. Он не решает проблему слежки — по крайней мере без настроек из первого способа, — но позволяет не захламлять систему кучей бесполезного софта, который будет висеть в фоне и жрать память. Суть проста — ставим кастомную прошивку и заливаем поверх нее минималистичную версию gapps, которая включает в себя только Google Play.
Таких минимальных сборок gapps в Сети множество, но я бы рекомендовал использовать проверенные временем BaNkS Gapps, а именно файл «месяц-числоGAppsCore4.4.2signed.zip». Они работают на любом смартфоне, совместимы с ART и включают в себя только основные файлы gapps, список которых приведен в разделе «Что такое Gapps», файлы фреймворка, а также несколько библиотек. По сути, это Google Play, инструменты синхронизации и ничего больше.
Меняем поисковик на DuckDuckGo
Даже после полного отключения синхронизации на домашнем экране останется «встроенная» строка поиска Google. В стоковых прошивках некоторых производителей (Samsung, например) это всего лишь виджет, который можно легко удалить с экрана. В чистом Android и девайсах от многих других производителей она «вшита» в домашний экран, но ее можно убрать, отключив весь поиск от Google (вместе с Google Now) с помощью меню «Настройки -> Приложения -> Все -> Google поиск -> Отключить» или установив сторонний лаунчер. Далее достаточно скачать из маркета или другого магазина приложений DuckDuckGo и добавить одноименный виджет на домашний экран.
Сторонний маркет
Второй и третий способ предполагают полное избавление от Google Apps, включая Google Play и возможность логина с помощью Google-аккаунта, поэтому мы должны найти способ простой и удобной установки приложений, который не заставлял бы нас выкачивать их самостоятельно, а затем скидывать на карту памяти и устанавливать вручную. Один из таких способов — установить сторонний маркет.
На данный момент существует три более или менее жизнеспособные альтернативы Google Play. Это Amazon Appstore, Yandex.Store и 1Mobile Market. У каждого из них есть свои преимущества и недостатки, которые в основном сводятся к количеству приложений и способам оплаты:
- Amazon Appstore — самый известный магазин приложений после Google Play. Содержит более 75 тысяч приложений (в сравнении с 800 тысячами в Google Play), качество каждого из которых проверяется вручную, так же как в iTunes для iOS. Расплачиваться можно с помощью кредитной карты или амазоновскими монетами (Amazon Coins), которые дают в качестве подарка за покупку планшета Kindle Fire либо в подарок от другого юзера. Одна из самых интересных черт магазина — ежедневная бесплатная раздача одного из платных приложений.
- Yandex.Store — магазин от компании «Яндекс». Содержит более 85 тысяч приложений, каждое из которых проверяется антивирусом Касперского. Особо ничем не выделяется, но зато имеет киллер-фичу в виде возможности оплачивать покупки с помощью сервиса Яндекс.Деньги или счета мобильного телефона.
- 1Mobile Market — крупнейший сторонний репозиторий Android-приложений, включающий в себя более 500 тысяч софтин. Отличается от других наличием исключительно бесплатных приложений (не путать с пиратскими), из-за чего позволяет не проходить стадию регистрации аккаунта и сохранить анонимность.
Приложения во всех трех маркетах имеют оригинальные цифровые подписи разработчиков приложений, что позволяет использовать их одновременно. Приложение, установленное из одного маркета, может быть без проблем обновлено из другого, а при удалении пропадет из списка установленных сразу во всех. Покупать, правда, придется раздельно.
Amazon Appstore
Yandex.Market
1Mobile Market
Open Source Маркет
Кроме описанных в статье, а также множества других менее известных магазинов приложений, в Сети можно найти отличающийся от остальных репозиторий F-Droid. Он полностью анонимен и содержит только свободный софт, распространяемый под лицензиями, одобренными фондом FSF. Приложений в F-Droid всего тысяча, зато все они гарантированно не содержат бэкдоров и других систем разглашения личных данных. Именно F-Droid используется в качестве дефолтового маркета в свободной Android-прошивке Replicant.
Решение проблемы зависимости приложений от Google Apps
Несмотря на то что компоненты gapps не являются частью официального API Android, некоторые приложения все-таки ожидают увидеть их в системе, из-за чего может возникнуть ряд проблем — от полной неработоспособности приложения до потери части его функций. Некоторые приложения откажутся устанавливаться из-за отсутствия Google Maps API, другие падают сразу после запуска, не обнаружив его, третьи включают в себя прямые ссылки на Google Play, что может привести к падениям и некорректной работе.
Чтобы решить эти проблемы, пользователь MaR-V-iN с XDA начал проект NOGAPPS, в рамках которого ведется разработка набора открытых компонентов, заменяющих оригинальную функциональность Google Apps. В данный момент доступно три компонента-замены:
- Network Location — сервис геолокации на основе Wi-Fi и базовых станций GSM. Основан на базе данных IP-адресов от Apple и открытой базе базовых станций;
- Maps API — замена интерфейса к Google Maps на основе OpenStreetMap;
- BlankStore — открытая альтернатива клиенту Play Store. Позволяет устанавливать бесплатные приложения из магазина Google, но не рекомендуется к использованию из-за возможных санкций со стороны поисковика (это запрещено их правилами).
Установка компонентов производится отдельно и разными способами. Network Location достаточно вручную скопировать в каталог /system/app/ в Android 2.3–4.3 или в каталог /system/priv-app/ в KitKat (в этом случае следует использовать файл NetworkLocation-gms.apk). Maps API устанавливается с помощью прошивки файла nogapps-maps.zip через консоль восстановления. Для установки маркета придется не только копировать файл, но и генерировать Android ID на большой машине, но, так как делать это не рекомендуется, я не буду об этом рассказывать и ограничусь ссылкой на инструкцию.
После всех манипуляций софт должен корректно заработать.
Выводы
Для компании Google Android без ее собственных приложений бесполезен, поэтому нет ничего удивительного в том, что компания выносит в них самые вкусные части системы и оставляет код закрытым. Однако в этой статье я показал, что жизнь без gapps есть и она может быть даже проще и удобнее, чем с Google.
[authors]
Евгений Зобнин
Редактор рубрики X-Mobile. По совместительству сисадмин. Большой фанат Linux, Plan 9, гаджетов и древних видеоигр.
Источник