Network stack android что это

Взаимодействие Android-устройств в локальной сети

Предположим, мы пишем игру для Android, которая подразумевает некое сетевое взаимодействие между устройствами. Причем наши устройства находятся в одной сети и мы хотим, чтобы взаимодействие между ними осуществлялось быстро, а значит вариант с обменом данными через интернет нам не подходит. Ах да, еще одна маленькая ложка дегтя — мы хотим охватить максимально возможную аудиторию, для чего нам необходимо поддерживать Android 2.3.
Что же нам делать? Давайте поговорим об этом, а заодно рассмотрим относительно новые возможности Android SDK для соединения двух и более устройств.

О чем это и для кого это?

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

Какие возможные способы решения существуют?

1. Android Network Service Discovery. Простой и эффективный способ обнаружения устройств. На Android Developer есть пошаговое руководство по подключению NSD, есть пример NsdChat, который можно скачать там же. Но есть один существенный минус — данный метод поддерживается только начиная с API Level 16, то есть с Android 4.1 Jelly Bean;
2. Второе решение, предлагаемое нам на сайте Android Developer — Wi-Fi Peer-to-Peer. Проблема этого метода та же самая — поддерживается он только начиная с API Level 16;
3. Есть странное решение, которое предлагается некоторыми программистами на Stack Overflow — самостоятельно сканировать локальную сеть на предмет наличия сервера. То есть проходить по всем адресам сети. Это уже сейчас звучит как странный велосипед, а теперь представьте, что порт нашего сервера назначается автоматически. Таким образом, сканирование даже самую небольшой сети становится достаточно долгой и трудоемкой задачей;
4. Наконец, мы можем обратить внимание на Java-библиотеки и написать что-нибудь с их использованием. Например, JmDNS.

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

Я вооружился JmDNS и решил попробовать соорудить несколько классов, которые по максимуму упростят написание описанных выше приложений. Но для начала пришлось немного повырезать дубликаты .class-файлов из jar-пакета JmDNS (проблема описана здесь):

Далее я взял исходный код NsdChat с Android Developer и изменил его служебный класс, который отвечает за инициализацию сокетов и организацию сетевого взаимодействия. Также я написал wrapper для JmDNS

Здесь размещены 4 основные функции для работы Network Discovery:

1. startServer для создания сервера и регистрации соответствующего сервиса в локальной сети;
2. findServers для поиска серверов;
3. reset для окончания работы с Network Discovery и последующего освобождения ресурсов;
4. wifiLock для запроса блокировки Wi-Fi.

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

А вот и mServerHandler, использующийся для приема и обработки сообщений:

Отправка сообщений еще проще:

И, наконец, метод для обнаружения и подключения к серверу:

Как видите, все очень просто. А главное, все это работает в любой версии Android для максимум двух устройств. Но сделать так, чтобы это работало для условно неограниченного числа устройств очень легко, и очевидное решение придет к вам почти сразу после детального изучения класса Connection. Пусть это будет в качестве домашнего задания.
Ах, да, весь код доступен для изучения и использования всеми желающими в моем репозитории на GitHub.. И, конечно, не исключаю то, что некоторые вещи можно сделать лучше и проще, поэтому не стесняйтесь форкать и делать pull request’ы.

Источник

[Советы] Оптимизация автономности смартфона: Разряд аккумулятора [Часть 1]

Часть 1.png (3.09 MB, Downloads: 31)

2018-06-05 12:40:47 Upload

qxkEbu.png (869.68 KB, Downloads: 57)

2018-06-01 14:25:15 Upload

IMG_20180601_150417.jpg (126.28 KB, Downloads: 56)

2018-06-01 16:06:25 Upload

IMG_20180601_150056.jpg (201.93 KB, Downloads: 71)

2018-06-01 16:06:24 Upload

• Способы ввода (com.android.inputdevices) — раскладка клавиатуры;
• com.qualcomm.qti.tetherservice — что-то связанное с сетями ;
• org.codeaurora.btmultisim — что-то связанное с 2-мя сим-картами;
• com.miui.system и com.miui.rom — собственно сама MIUI;
• Телефон (com.android.server.telecom и com.android.phone) — собственно сама служба и управление ей;
• com.qualcomm.timeservice — служба синхронизации времени;
• Настройки (com.android.settings и com.xiaomi.providers.appindex) — сервисы настроек смартфона, удалять не безопасно;
• Сервис безопасности интерфейса (com.qualcomm.qti.services.secureui) — Служба QTI — сервис безопасности UI;
• Fused Location (com.android.location.fused) — сервис определения местоположения по мобильной сети и Wi-Fi. При отключении или удалении данного сервиса имеется большая вероятность поймать бутлуп, а так же невозможность выполнить Hard Reset. Возможно наличие и других проблем с работой смартфона;
• Хранилище настроек (com.android.providers.settings) — возможно, сохранение/хранение и бэкап настроек смартфона. Так или иначе служба является основной;
• Application Extension Service (com.miui.contentcatcher) — возможно, данная служба отвечает за обновления/работу приложений;
• Связка ключей/Брелок (com.android.keychain) — важный компонент системы, предоставляет доступ к закрытым ключам и их соответствующим сертификатам в хранилище учетных данных;
• com.android.keyguard — возможно, служба управления блокировкой локскрина. Точное назначение службы понять не смог, но точно ясно, что она относится к локскрину и ключам безопасности;
• Уведомления (com.android.systemui) — основной сервис Android, отвечает за настройку графического интерфейса;
• Система Андроид — основной компонент ОС Android;
• com.quicinc.cne.CNEService — движок 3G/4G и WiFi подключений на базе Qualcomm. Сервис автоматически выбирает когда ему лучше использовать Wi-Fi, а когда 3/4g. На XDA пишут, что ничего страшного при отключении не происходило, так же и мной ничего страшного обнаружено не было;
• com.qti.service.colorservice — вероятно, сервис отвечает за смену цветовой температуры и контрастности экрана;
• WMService (com.miui.wmsvc) — .
• com.mi.dlabs.vr — вероятнее всего компонент для приложения Mi Vr App (com.mi.dlabs.vr.hulk) для Vr-очков. Ни каких сбоев и нарушение работы приложений при отключении я не обнаружил;
• Адаптивная подсветка (com.qualcomm.cabl) — точных данных о работе сервиса найти не удалось. На XDA пишут, что это оптимизация яркости подсветки экрана для каждого приложения отдельно. Этот сервис не связан с работой автоматической яркости. Для отключения советуют изменить параметр ro.qualcomm.cabl=1 на ro.qualcomm.cabl=0 в buil.prop если замечаете некие изменения яркости экрана при отключеной автоматической яркости. Отключение или удаление данного сервиса иными путями только для желающих поэксперементировать;
• Инженерное меню (com.miui.cit) — аппаратная диагностика устройства. Ознакомиться подробнее можно здесь. Отключение не желательно, но возможно;
• Оптимизация системы (com.miui.whetstone) — Утилита, собирающая информацию о производительности одного процессора, в сравнении с другими. Не рекомендуется отключать, если используете стоковое ядро. У меня стоит кастом, поэтому я отключил за бесполезностью;
• MiuiDaemon (com.miui.daemon) — спорный сервис, где-то пишут, что это сервис мониторинга и отправки данных (а-ля тотальный заговор против конфидециальности человечества), а где-то пишут, что это сервис управления производительностью (ядром). При отключении данного сервиса мне не удалось обнаружить падений системы и сбоев в работе;
• Настройки SVI (com.qualcomm.svi) — понять назначение сервиса точно не удалось, сервис возможно связан с адаптивной подсветкой, как вариант улучшение отображения при солнечном свете. Так же может быть связано с передачей изображения на монитор/телевизор. При отключении ничего страшного не происходит;
• LocationServices (com.qualcomm.location) — определения местоположения компании Qualcomm, основанные на технологии позиционирования внутри помещений WiFi и облачных хранилищ. Есть мнение, что данный сервис бесполезен;
• Сервис WiDi (com.qualcomm.wfd.service) — WiFi Direct;
• com.qti.dpmserviceapp — сервис воспроизведения видео- и музыкального контента с DRM защитой;
• Пользователи устройства (com.miui.securitycore) — ключевой компонент «второго пространства»;
• Сервис ANT HAL (com.dsi.ant.server) — поддержка устройств ANT+ (пульсометры, велокомпьютеры и т.д.);
• Отчеты (com.miui.bugreport) — служба отправки отчетов разработчикам MIUI;
• Очистка (com.miui.cleanmaster) — служба очистки свободного пространства MIUI. Далеко не самая лучшая, особенно для Root-пользователя;
• com.xiaomi.joyose — ходят слухи, что сервис относится к китайским развлекательным сервисам (сбор музыки, видеороликов, шагометр и т.д.). При отключении ничего страшного не произошло, музыка везде играет, видео воспроизводится. Шагометрами и подобной ерундой не пользуюсь;
• SpacesManagerService (com.securespaces.android.ssm.service) — приложение второго пространства;
• Запись экрана (com.miui.screenrecoder) — тут и так все понятно;
• com.android.wallpaperbackup — судя по названию, скорее всего, сервис отвечает за системный бэкап изображений в галлерее. Если пользуетесь сторонним приложением для бэкапа или облаком (гугл драйв, мега, яндекс диск и т.д.), смело отключаем;
• Безопасность (com.miui.securitycenter) — центр управления безопасностью смартфона. Для root-пользователя не особо полезная программа, скорее даже наоборот. Заморозка программы ни к чему критичному не приводит, если не одно НО! Данное приложение обладает иммунитетом к остановке/заморозке, т.е. ее невозможно выключить на многих смартфонах на MIUI 9;
• CloudServiceSysbase (com.miui.cloudservice.sysbase) — сервис связанный с Mi Cloud, скорее всего с активацией и работой;
• com.miui.antispam — служба блокировки неизвестных номеров, компонент «Безопасности»;
• Батарея и производительность (com.miui.powerkeeper) — сервис мониторинга батареи и управления зарядом. Довольно слабая вещь для root-пользователя, существует мнение, что более бесполезно, чем полезно. При отключении становится недоступен раздел Настройки — Батарея и производительность, но в него можно попасть через приложение «Безопасность» раздел Батарея, так же в этом разделе исчезает пункт Экономия батареи, он нам по сути и не нужен, только больше садит батарею;
• com.securespaces.android.sscm.service — компонент «второго пространства»;
• Провайдер настроек (com.android.provision) — сервис сохранения настройки Мастера настройки (SetupWizard). Сохраняет информацию о том, что устройство было подготовлено. Можно отключить после первого включения и настройки смартфона;
• Помощник нажатий (com.miui.touchassistant) — плавающий виджет для быстрого запуска;

2. Сервисы Google Play
Наверное самая пакостная штука, которая есть в смартфоне, это сервисы Google Play. Насколько они полезны, настолько же они и вредны, в этом и заключается их главная пакость. Данные сервисы обеспечивают работу практически всего смартфона, если не напрямую, то через привязку к остальным приложениям. Удалить их или отключить невозможно, т.к. они обеспечивают работу уведомлений практически в любом приложении, работу сервиса определения местоположения, бэкапы данных, синхронизацию с аккаунтом Google, работу всех приложений Google и построеных на их основе и еще очень много всего. Основной минус сервисов в том, что они содержат максимальный комплект, не зависимо от спецификации смартфона и их нельзя настроить или остановить ненужные штатными методами. А если проверить раздел Настройки — Батарея и производительность — Питание, вы обнаружите, что основным главным врагом аккумулятора являются именно данные сервисы.

Существует два способа борьбы с сервисами Google Play:

• Первый способ — замена стандартных сервисов на microG GmsCore;

Главный плюс microG — они практически не расходуют заряд смартфона, при постоянном подключении смартфона к сети и работе с приложениями, геолокацией и т.д. данные сервисы расходуют лишь 0,5-2% всего заряда. Это очень круто!
Но все же, я отказался от данной реализации сервисов, именно из-за их нестабильности и конечно же из-за игр (я задрот, что поделаешь).

• Второй способ — отключение компонентов сервисов Google Play, которые приводят к фоновой работе определенных бесполезных для пользователя сервисов.

Данный способ требует большой внимательности, сообразительности и достаточно много времени для настройки работы сервисов «под себя». Производится настройка сервисов GP при помощи приложения My Android Toolsили его аналогов, но я советую именно данное приложение. Про работу с данным приложением я опишу позже, либо вы можете сами ознакомиться с его функционалом, кликнув по названию данного приложения и перейдя на 4PDA.
Данный способ позволяет тонко настроить работу сервисов Google Play, что приводит к значительному снижению потребления как заряда аккумулятора смартфона, так и небольшому освобождению RAM (оперативной памяти) без потери работоспособности нужных вам сервисов.

Источник