Сергей Бугаев bugaevc

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

Совсем не безлимитно; в новых версиях (Oreo, Pie) на сервисы наложили серьёзные ограничения, уже нельзя просто так завести сервис и тратить ресурсы. Про это я немного подробнее рассказал в прошлой статье.

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

Во-первых, большинство функций recovery по обновлению системы в схеме с A/B-обновлениями выполняет сама система, так что recovery можно сильно упростить (а значит, она будет занимать меньше места). Во-вторых, не нужен раздел cache, на который раньше скачивались обновления перед установкой. В-третьих, вместо того, чтобы хранить odex-файлы предустановленных приложений в разделе system (а они, вроде бы, занимают половину её объёма), можно исходно сохранить их на system_b (вместо образа системы), откуда при первом запуске скопировать в data; а после этого уже использовать system_b по назначению.

Google говорят, что у них на Pixel в результате этих оптимизаций для A/B-схемы потратилось только 320 дополнительных мегабайт по сравнению со старой схемой. Подробнее здесь и ещё вот здесь.

Смотрите, разница здесь вот какая. Графический ключ, пин-коды, пароль и т.п. — это чистый, статический кусок информации. Его можно сравнивать (совпадает пароль или не совпадает?), его можно хранить, от него можно взять хэш, на его основе можно создавать ключ шифрования данных и так далее.

А система распознавания отпечатка пальца, лица, радужки глаза… — это именно система распознавания. Она может решить, владелец устройства приложил палец или кто-то другой. В каком-то виде она, конечно, хранит характеристики этого пальца, чтобы его узнавать; но, во-первых, это какая-то нечётная модель, во-вторых, такие характеристики пальца из себя ничего секретного не представляют и создавать на их основе ключ было бы небезопасно.

Повторю другими словами: в одном случае у нас есть явный и устойчивый кусок информации, который нужно сравнивать с другим куском информации (а ещё можно использовать для генерации ключа). В другом случае у нас есть некоторая функция, чёрный ящик, которая возвращает boolean — правильный ли палец прикладывают. Это здорово для аутентификации (не нужно запоминать пароль!), но секретный ключ на основе этого не сгенерировать.

Так работает новый механизм обновления системы. Одномернно хранятся две версии каждого системного раздела (boot_a, boot_b, system_a, system_b, vendor_a, vendor_b — а вот к разделу data это, конечно, не относится). Один из них этих слотов считается активным, и именно с него загружается система (то есть, если, например, активен слот a, то bootloader загружает ядро и initramfs из boot_a, /system монтируется из system_a и т.д.). В другом слоте остаётся прошлая версия системы — или, наоборот, только что загруженная новая версия, в которую устройство загрузится при следующей перезагрузке. Подробнее можно почитать здесь, здесь и здесь.

Следующая часть наконец-то вышла: https://habr.com/company/solarsecurity/blog/427431/

Четвёртая статья: https://habr.com/company/solarsecurity/blog/427431/

Я наконец написал продолжение! https://habr.com/company/solarsecurity/blog/427431/

Да, можно и нужно использовать систему типов для таких вещей. Проблема в том, что это решение принимает разработчик библиотеки для работы с БД, а не автор конченой программы (и тем более не анализатор). И в случае JDBC, например, запросы передаются в виде String sql.

Так что конечно было бы лучше, если бы все использовали систему типов, но анализатор всё равно должен уметь находить SQL-инъекции в коде, который использует «сырые» строки.

Есть достаточно хорошие биндинги для GTK, glib и всей g-экосистемы: https://gtk-rs.org. Есть rust-qt-binding-generator. Но вообще для GUI Rust не очень-то подходит с его моделью памяти (ownership, отсутствие классов и наследования...); имеет смысл писать на Rust ядро/бэкэнд, а GUI — на более «родном» для платформы языке (Vala, Objective-C, Kotlin, ...)

Разным анализаторам нужно разное. Кто-то работает на исходном коде (или, например, на AST, который сам же строит по исходному коду), а кому-то «достаточно» бинарника (в кавычках, потому что это не обязательно меньшее требование — как описано в статье, собрать исходники может быть не так тривиально). Это может быть или совсем «нативный» бинарник (например, для C/C++), или набор class-файлов для Java/Kotlin/Scala — и class-файлы, кстати, во многом сохраняют семантику исходного кода, в большей степени, чем «совсем бинарники».

С бинарниками ещё возникает сложность с тем, чтобы найденную уязвимость пользователю отобразить — нельзя же написать, что «в библиотеке Foo есть SQL-инъекция». Более крутые анализаторы способны декомпилировать бинарник и сопоставить место, где нашли в нём уязвимость, строчке в декомпилированном коде.

А если они с исходным кодом, то что мешает их исправлять?

Может быть, их исходный код и доступен (в публичном репозитории), но чтобы внести туда свои правки, нужно делать форк, pull request, ждать следующего релиза и т.д. Альтернативно, можно, конечно, собирать проект со своей копией библиотеки, а не пытаться исправить уязвимость в upstream'е, но это много другой головной боли.

Официально мы про это пока ничего не объявляли, но создалось правильно, следите за новостями ;)

Посещала!

В принципе, похожие проекты уже есть, например, PureDarwin и GNU-Darwin, хотя у них, вроде как, нет Cocoa и всего высокоуровнего стека для macOS-приложений. Впрочем они могли бы, как мы, использовать реализации из проектов The Cocotron или GNUstep.

Проблема с созданием полноценной системы в том, что для неё требуется сильно больше, чем ядро и bash, нужны разнообразные драйвера, сервисы, графическая подсистема и т.п. В Linux всё это уже есть — и драйвера под практически любое оборудование, и системные сервисы вроде тех же udev, PulseAudio/PipeWire, wpa_supplicant и NetworkManager, и крутая современная графическая подсистема (DRM, KMS, Mesa, Vulkan, Wayland). В Darling мы стараемся максимально облегчить сам контейнер и использовать уже существующие на хосте сервисы, библиотеки и т.д. Для потенциальной DarlingOS пришлось бы или всё это перереализовывать, или пытаться портировать с Linux, или отказаться от большинства того, что отличает современную операционную систему от Unix 70-х годов.

Ну и потом, основная мотивация разрабатывать ReactOS вместо того, чтобы просто использовать Linux + Wine — jeditobe, поправьте меня, если я не прав :) — это потенциальная возможность использовать драйвера для Windows, которые часто всё-таки находятся в лучшем состоянии, чем их аналоги для Linux. А вот у macOS и iOS едва ли есть в этом плане преимущество перед Linux, поэтому вариант Linux + Darling подойдёт лучше всего.

Именно! Спасибо, стараемся :)

Рассчитывать не стоит и не гарантирован (когда по памяти завершают, иначе гарантирован), но в документации явно написано, что система может его вызвать в такой ситуации:

onDestroy()

Called before the activity is destroyed. This is the final call that the activity receives. The system either invokes this callback because the activity is finishing due to someone's calling finish(), or because the system is temporarily destroying the process containing the activity to save space. You can distinguish between these two scenarios with the isFinishing() method. The system may also call this method when an orientation change occurs, and then immediately call onCreate() to recreate the process (and the components that it contains) in the new orientation.

Нет, переход на ART вряд ли повлиял на работу сетевых соединений.

(Этот абзац не специфичен для Android, а верен на любой Linux-системе) Действительно, система может освобождать занятые порты не сразу после завершения державшего их процесса, а только после отправки всех буферизованных данных (это называется socket linger, и с этим часто борются с помощью SO_REUSEADDR), но это актуально для портов с заранее известным номером. Если вы просто делаете POST-запрос, система автоматически назначит вам подходящий свободный порт, и этой проблемы не возникнет.

Хабр — не Тостер, но думаю, вам стоит посмотреть с помощью сниффера, в чём разница в успешных и неуспешных запросах, как вам и порекомендовали на StackOverflow.

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

Наверно, я не очень удачно сформулировал. Конечно же, основной механизм освобождения памяти в Android — завершение всего неиспользуемого. Вопрос только в том, может ли приложение перейти из состояния «activity1 работает, acivity2 работает» напрямую в состояние «activity1 работает, acivity2 завершена», или только через состояние «activity1 заврешена, acivity2 завершена, процесс убит».

Переформулировал этот кусок в статье.

К сожалению, этот вопрос плохо описан в документации. Насколько я понимаю, здесь есть такие особенности:

• при нехватке памяти система действительно завершает процессы целиком, при этом она может вызвать, а может и не вызвать onDestroy() у запущенных компонентов;
• когда activity завершается не прямо перед завершением всего процесса (а, например, при повороте экрана), onDestroy() вызывается обязательно, но освобождение памяти самой activity происходит через обычный механизм сборки мусора (в том числе, если сохранить лишнюю ссылку, будет activity leak).

Но здесь нужно помнить, что запуск и завершение процесса — это всё-таки более низкий уровень, чем жизненный цикл компонентов приложения. Процитирую первую статью:

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

То есть на этом более высоком уровне — как я описал в статье — может так получиться, что из двух копий activity одна запущена, а другая полностью завершена — например, если пользователь вернулся в одну из этих копий после того, как (на низком уровне) процесс был завершён из-за временной нехватки памяти, а потом запущен снова.

Да, ждёт в блокирующем вызове ioctl(binder_fd, BINDER_WRITE_READ, &bwd) — он работает примерно так же, как write() и read() подряд на этом дескрипторе. Вот реализация этого ioctl со стороны ядра.

Да, binder_fd поддерживает и poll, но обычно процессы блокируют свой основной поток (он же looper thread, он же UI thread в приложениях) на binder_write_read и делают остальное блокирующее I/O (например, сетевые запросы) в других потоках.

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

Конечно есть! Обычные pipe-ы никуда не делись (Android is Linux), правда совсем не очевидно, как их прокидывать из одного приложения в другое. Основной механизм IPC на Android — Binder, про который я рассказывал в первой статье.

Я опять приведу в качестве примера Google Play Services — приложение, которое не имеет собственного интерфейса, но реализует разнообразную функциональность, которой пользуются (подключаясь к нему через Binder) другие приложения.

Да, именно в этом и есть смысл разделения на activity (GUI), которые могут запускаться, когда нужно, завершаться и перезагружаться; и сервисы, которые остаются запущенными даже без activity. Нет, всё это происходит в рамках одного приложения, конечно.

Но, как я рассказал в статье, Android 8 не позволяет таким приложениям поддерживать соединение в фоне (и вообще серьёзно ограничивает фоновые сервисы); вместо этого нужно использовать push-сервисы вроде Firebase Cloud Messaging. Вероятно, многие из этих приложений так и делают.

С другой стороны, пока что Viber и WhatsApp работают на Oreo в режиме совместимости (у обоих target SDK < 26), то есть на них эти ограничения не распространяются.

Честно говоря, именно с callback hell я в Android не встречался, но есть и много других, мягко говоря, сложностей, с которыми приходится сталкиваться разработчику — в основном это вопросы архитектуры приложения и правильной работы с lifecycle (в том числе фрагментов). Решается это использованием реактивных библиотек вроде RxJava или новых Android Architecture Components. Подробнее об этом я собираюсь рассказать в одной из следующих статей.

Я именно про Oreo и говорю, и выше процитировал именно ту страницу, на которую вы дали ссылку.

Да, это пример lock-in'а. С другой стороны, ничто не мешает кому-нибудь разработать свободный (или просто свой) аналог Play Services и использовать его.

Не просто с меньшей вероятностью.

Во-первых, это логично и правильно: это независимое действие, а не часть какой-то activity. (Аналогично: зачем разделять программу на функции и классы?)

Во-вторых, некоторые гарантии выполнения после выхода из activity всё-таки есть:

When an app goes into the background, it has a window of several minutes in which it is still allowed to create and use services. At the end of that window, the app is considered to be idle. At this time, the system stops the app's background services, just as if the app had called the services' Service.stopSelf() methods. Under certain circumstances, a background app is placed on a temporary whitelist for several minutes. While an app is on the whitelist, it can launch services without limitation, and its background services are permitted to run.

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

С точки зрения низкоуровневой реализации часть разрешений проверяется ядром (разрешение на доступ к сети, на доступ к файлам устройств, на доступ к файлам пользователя...), поэтому они должны быть экспортированы на уровень ядра в виде GID (в packages.xml они тоже записаны, конечно). Для остальных разрешений это не нужно и неудобно (при изменении GID приложение нужно перезапустить, что делается прозрачно для пользователя, но всё-таки лучше делать это реже).

(не туда)

AOT означает, что приложение компилируется до (ahead of) выполнения. Это можно делать сразу же при установке (и именно так это работало в Lollipop и Marshmallow) или в какое-то другое время между установкой и запуском (не обязательно прямо перед запуском; так это работает, начиная с Nougat). Новый способ заметно лучше старого — в том числе и потому, что позволяет потом перекомпилировать приложение с учётом данных профилирования.

То, что вы описали, и есть AOT.

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

Вот именно поэтому это и opt-in. Да, кастомные сборки могут насильно переносить приложение, даже если оно не рассчитано на то, что его части начнут внезапно отваливаться.

Возможность устанавливать приложения на SD-карту никуда не убрали, но это opt-in со стороны приложения — по умолчанию installLocation="internalOnly". Да, при этом данные приложения помещаются в специальный зашифрованный asec-контейнер на карточке. Как написано в документации, это в основном актуально для больших игр.

Я специально в этой серии статей почти везде пишу имена в оригинале — на мой взгляд, так получается лучше. Другими словами, не баг, а фича :)

UPD: про это будет в третьей статье.

Спасибо, вы совершенно правы. Исправил в статье.

Спасибо!

Нет — к сожалению планов писать про iOS пока нет, но если вы интересуетесь, могу порекомендовать книгу Mac OS X and iOS Internals: To the Apple's Core, автор Jonathan Levin.

Спасибо! У меня есть идеи для пяти статей (то есть ещё трёх), но может получиться и больше.