2014-09-29

О прошивке Андроида

Попробую собрать воедино тайные знания о том, как перепрошивать Андроид устройства. Тут много малопонятных терминов и загадочных процедур. Постараюсь обобщить.
Android Gears
ВНИМАНИЕ! Все прошивки, рекавери и прочее собираются энтузиастами. В лучшем случае (например, CyanogenMod) — сообществом энтузиастов. Но весьма часто и анонимными индивидуумами. Так что нет никаких гарантий, что после перепрошивки все будет работать как надо. В том числе и я не даю никаких гарантий, что, прочтя этот пост, вы сможете безболезненно перепрошить любое устройство. Действуйте на свой страх и риск. И помните, что любое изменение прошивки вашего устройства как правило лишает вас гарантии.
Начнем с терминологии.
Рекавери (recovery). Это некий аналог bios setup. Программа, которая хранится в отдельной специальной памяти устройства. И которая может быть запущена при загрузке (перезагрузке) устройства. И которая позволяет делать всякие страшные действия, пока основная ОС не запущена.
В устройстве всегда уже есть штатное рекавери. Оно запускается при обновлении прошивки «по воздуху». Тот самый зеленый робот с шестеренками в животе — это картинка, отображаемая штатным рекавери. А вот чтобы поставить какую-то другую прошивку — нужно прошить кастомное рекавери.
Рекавери доступны в виде образов (.img файлов).
Recovery screenshot
Что можно сделать в рекавери? Перезагрузить устройство (уже в обычном режиме). Установить zip архив (об этом ниже). Вайпнуть разделы (тоже ниже). Забэкапить и отресторить само рекавери и, иногда, разделы и приложения.
ClockworkMod (CWM, CWMR) — один из самых популярных рекавери. Существует в двух версиях. В «обычной» версии навигация по меню осуществляется клавишами (теми немногими, что остались) устройства: громкость тише/кромче — это вверх/вниз и т.п. В «touch» версии можно все тыкать пальцами, что конечно, удобнее. На современных устройствах нет противопоказаний против touch версии, ставьте её.
Вайп (wipe). Это форматирование ( удаление всех данных! ) раздела. Дискового раздела, ну точнее раздела встроенной флэш-памяти. Дело в том, что в Андроид имеется несколько разделов.
boot — это раздел в Линукс ядром. Как правило явно вайпать его не нужно. (А если вайпните по ошибке — все пропало :)
В system хранятся системные (предустановленные) приложения и данные. Вайпать этот раздел нужно только если вы собираетесь ставить абсолютно новую прошивку.
В data устанавливаются пользовательские приложения и хранятся пользовательские данные. Ну кроме тех данных, что помещаются на SD карту, реальную или виртуальную. Стандартная штука «Сбросить на заводские настройки» как раз и вайпает этот раздел. Соответственно, делайте это, если хотите удалить все приложения (и данные), кроме предустановленных.
cache — это кэш. Кэш Далвика (Dalvik, ява-машины в Андроид) и не только. Сюда помещаются всякие оптимизационные данные, чтобы приложения запускались и работали быстрее. Именно в этот раздел что-то записывается, когда, после обновления прошивки, Андроид радостно сообщает об «оптимизации 50 из 100500 приложений». Может, видели. Иногда бывает, что некоторые глюки приложений лечатся вайпом этого раздела. Жизненно необходимо его вайпать при обновлении прошивки.
Android Partitions
Прошивка (ROM, custom ROM). Это «образ» системы. Которым вы заменяете штатную систему (ну или ту, которая установлена на данный момент).
Если в десктопном мире под образом системы понимают образ жесткого диска или CD, то «образ» прошивки Андроида — это обычный zip архив. Этот архив содержит обычные файлы, которые распаковываются в обычные каталоги в файловой системе устройства. Соответственно, то, что распаковывается в /system замещает системные файлы (потому нужно делать вайп этого раздела, чтобы не остались ошметки старой прошивки).
Впрочем, этот zip архив может содержать и готовые образы (.img, в «десктопном» смысле), например, для /boot раздела. Также файлы в архиве подписаны (примерно так, как делается в явовых .jar архивах). И имеются скрипты, которые выполняются при установке архива.
Найти прошивки можно в основном на 4PDA или XDA. Это форумы (кто сказал, что форумы вымерли?), и поиск там оставляет желать лучшего. Но они успешно индексируются Гуглом.
CyanogenMod (Цианоген, Циан) — самая популярная кастомная прошивка. Если не знаете, чем прошиваться, попробуйте Цианоген. Чаще всего Цианоген — не самая быстрая прошивка (если у вас старое устройство и вы хотите выжать все, что можно). Потому что он стал грешить кучей предустановленного софта. Но почти всегда Цианоген — самая стабильная прошивка (из кастомных, естественно).
Гуглоприложения (GoogleApps, gapps). Кастомные прошивки не содержат «стандартных» гугловых приложений вроде Google Play, Gmail и т.п. Потому что эти приложения — проприетарные, и их нельзя так просто распространять. Но их все же можно скачать и установить.
Это обычные zip архивы. Такие же, как прошивка. Просто содержат меньше файлов. И прошиваются точно так же.
Радио (radio, radio module). Кроме рекавери есть еще одна область памяти. Программа радио-модуля. Того самого, который GSM, GPS, Bluetooth, Wi-Fi и т.д. У него тоже есть какая-то программа и её можно обновить. Это всегда какой-то .img файл неясного происхождения. Говорят, если прошить на более новую версию, радиофункции могут начать работать лучше, могут исправиться какие-нибудь глюки. Помните только, что этот образ сильно завязан на конкретное железо. А железо может быть разным даже для одной и той же модели телефона. Будьте внимательны.
Бутлоадер (bootloader). Это еще одна программа и еще одна область памяти, которую можно прошить. Это системный загрузчик, который грузит либо рекавери, либо систему. Это он показывает красивую анимацию при загрузке устройства. Это еще один режим загрузки (кроме запуска основной ОС и рекавери), в который иногда нужно попасть, чтобы заменить рекавери. Иногда этот режим называют fastboot (об этом ниже).
Android Boot Modes
Лок (lock, unlock). Часто бывает, что рекавери или другие области памяти закрыты на запись. Залочены. Перед перепрошивкой эту блокировку надо снять. У хороших производителей это делается одной командой, напримерfastboot oem unlock. У плохих производителей нужна либо специальная утилита (причем работает она, небось, только под Windows), либо специальные хаки. Особо плохие производители могут ограничить количество разблокировок устройства, чтобы вам не захотелось слишком часто его перепрошивать.
Рут (root). Root — это суперпользователь в Unix. Такой пользователь может делать с системой все, что ему будет угодно. Обычные программы в Андроид никогда не имеют подобных прав. Но если «рутануть» устройство, то некоторые программы (вроде бэкапера или менеджера тех же прошивок) смогут получить эти самые права рута. В результате открываются некоторые интересные, но потенциально опасные возможности.
Технически рутование — это установка в систему юниксовой программы sudo (или su?) и некоей андроидной мордочки для контроля и раздачи прав. Другие программы, которые хотят рута, уже знают, что запустить и кого спросить.
Рута иногда нужно получить, чтобы появилась возможность перепрошить рекавери. А иногда нужно обновить рекавери, чтобы появилась возможность рутануть устройство. В особо запущенных случаях временное получение прав рута делается через известные уязвимости системы. Тут все индивидуально для разных моделей устройств.
fastboot. Утилита для работы с разделами и прошивками устройства, подключенного по USB. С недавних пор является частью Android SDK и доступна не только под Windows. Нужна для снятия локов, прошивки радио и рекавери, перезагрузки в разные режимы. Чтобы fastboot работал, устройство нужно перезагрузить в соответствующем режиме (bootloader, он же fastboot).
adb (Android Debug Bridge). Стандартная утилита для отладки андроидных программ (на устройстве, подключенном по USB). Тоже часть SDK. В данном случае нужна для перезагрузки в разные режимы, доступа к командной строке устройства (да, в Андроиде тоже есть шелл), копирования файлов на SD карту (или внутреннюю память устройства). adb работает, когда устройство загружено в нормальном режиме (загружен Андроид) и влючена отладка по USB в инструментах разработчика (об этом ниже).
Кирпич (окирпичить, brick, to brick). Так называют устройство, прошивка которого не удалась и устройство перестало загружаться. Получается дорогой кирпичик из пластика, металла, стекла и кремния. Существуют способы вывести устройство из такого состояния. Но тут все зависит от тяжести случая и конкретной модели устройства.
Androids
Последовательность прошивки индивидуальна у каждого устройства. Поэтому ищите инструкцию именно для своего девайса и следуйте ей. Но тем не менее, общие принципы соблюдаются. Их я и опишу. Хорошие инструкции, которые можно адаптировать под любые прошивки, имеются в вики CyanogenMod.
Вся процедура прошивки делается с «большого» компьютера под управлением Windows, Linux или MacOS (хотя сильно ощущается доминирование Windows среди прошивкоделателей). Андроид устройство должно быть подключено по USB.
  • Подготовка
    • Определите точную модель устройства, с точностью до версии аппаратного обеспечения (одна и та же модель, выпущенная в разное время и для разных регионов, может иметь разное железо).
    • Определитесь с прошивкой, которую собираетесь ставить.
    • Найдите подробные инструкции о том, как прошивать данную прошивку на данном устройстве.
    • Скачайте zip файл прошивки. Поместите файл в корень SD карты (или внутренней памяти) устройства.
    • Определитесь с версией рекавери. Скачайте img файл рекавери.
    • Определитесь с набором дополнительного ПО, которое хотите поставить вместе с прошивкой: gapps, рута и т.п. Скачайте zip архивы и скопируйте их на устройство.
    • Скачайте дополнительные утилиты (например, для снятия блокировки), если необходимо.
    • Скачайте и установите Android SDK. Под Windows вам понадобится еще установить USB драйвер.
    • Включите инструменты разработчика на устройстве. В Настройках зайдите в раздел «О телефоне» и быстро потыкайте по пункту «Версия ядра».
    • Включите «Отладку по USB» в настройках «Для разработчиков».
    • Полностью зарядите устройство (во время прошивки оно заряжаться не будет, и совсем плохо, если сядет батарея).
  • Прошивка
    • Подключите устройство к компьютеру USB кабелем.
    • Загрузитесь в режим fastboot. Для этого нужно сначала выключить устройство, а потом нажать хитрую комбинацию кнопок. Что-нибудь вроде Power + Volume Up + Volume Down. Или же может сработать командаadb reboot bootloader. Возможно, чтобы загрузиться в fastboot, вам понадобится рут. Сверяйтесь с инструкцией.
    • Разлочьте устройство. Тут все индивидуально. В простейшем случае может оказаться достаточным выполнить команду fastboot oem unlock.
    • Прошейте новое рекавери. В простейшем случае хватит команды fastboot flash recovery clockwork.img
    • Прошейте радио, если хотите. В простейшем случае хватит команды fastboot flash radio radio.img
    • Перезагрузитесь в режим рекавери. Иногда в рекавери можно перейти прямо из fastboot. Можно выключить устройство и нажать другую секретную комбинацию кнопок. Но чаще проще перезагрузить устройство в нормальный режим, а затем выполнить adb reboot recovery.
    • Забэкапьте вашу текущую прошивку. Это очень поможет, если вы захотите все вернуть назад.
    • Вайпните cache (всегда), system (если ставите абсолютно новую прошивку, а не обновление имеющейся), data (если хотите удалить понаставленные программы). Заметьте, что вы можете обновить прошивку и оставить все скачанные программы, если не вайпать data. Но тут возможны глюки.
    • Прошейте прошивку. Выберите «Install zip» и укажите zip файл прошивки, который вы заранее скопировали в память устройства.
    • Прошейте gapps, рута и прочее, что хотите. Точно так же выберите «Install zip» и укажите zip файлы в памяти устройства.
    • Перезагрузите устройство. Прямо из рекавери. Первая загрузка будет долгой. Очень долгой. Ведь cache наполняется.
    • Наслаждайтесь новой прошивкой.
    • ...
    • ПРОФИТ
CyanogenMod

2014-09-14

О Муми-троллях

Всем Добра. Раз уж День Программиста прошел, поговорим о Муми-троллях. Потому что Муми-тролли никакого отношения к программированию не имеют. И прошу не путать с владивостокским мяукающим Мумий Троллем.

Впрочем, одна связь с программированием все же прослеживается ;) «Муми-тролли (швед. Mumintroll) — центральные персонажи серии книг, написанной финской шведскоязычной писательницей Туве Янссон». «Родители Линуса, финские шведы...» (CC-BY-SA Википедия). Ой что еще готовят миру эти шведскоговорящие финны...


Итак, Муми-тролли. Это серия книг. Из девяти штук, если верить опять же Википедии (О ужас, девятой-то я не читал!). Написанных с 1945 по 1970 год. Эти книги я настоятельно рекомендую к прочтению детям и детьми любых возрастов, а также их родителями. Ибо...

Волшебные это книги. Потрясающе добрые. Милые и пушистые. Тут нет злодеев. Но полно приключений. И даже немного опасностей. И много добра. И правильных друзей. И правильных родителей. И много чего еще правильного.

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

По муми-троллям много раз пытались снять мультфильмы. И это понятно, и материал хороший, и авторские иллюстрации есть. Но я категорически неприемлю то, что получилось у отечественных мультоделов. Это ужасно. А как извратили Морру! Видел тут как-то и спектакль, тоже не понравился. Признаю только один замечательный мультсериал, сделанный совместно японцами и финнами. Японцы вообще замечательно фанатеют по муми-троллям и успешно объанимэшили их. Впрочем, у финнов и без японцев в последнее время получаются неплохие муми-тролльные мультики.

Ну давайте про героев. Многие герои имеют имя, совпадающее с их «расовой принадлежностью». Таковым, например, является и сам Муми-тролль, один из множества муми-троллей.

Муми-тролль. Юный главный герой. Романтик. Добрейшей души человек тролль. Отлично плавает. Любит приключения.

Муми-папа. Папа Муми-тролля. Основатель семейства и строитель Муми-дома. Романтик. Тоскует по приключениям, в результате устраивает их для всей семьи. Пишет мемуары. Когда у него что-то не получается, впадает в депрессию. В мультфильме постоянно носит цилиндр, хотя в книгах лишь раз его примерил.

Муми-мама. Мама Муми-тролля. Лучшая мама на свете. Совершенно спокойно справляется со всей оравой, живущей в Муми-доме. Знаменита своей сумочкой, с которой никогда не расстается. В этой сумочке находятся самые необходимые вещи: сухие носки, леденцы, порошки от желудка и много чего еще. В мультфильме почему-то всегда носит полосатый фартук.

Снорк. Представитель рода снорков. Снорки очень похожи на муми-троллей, только еще могут менять цвет. Приятель Муми-тролля. Типичный ботан. Любит все делать по правилам и записывать в дневник. Один раз даже устроил суд. В мультфильме носит очки и является маньяком-авиаконструктором (ну куда же в аниме без летающей вундервафли).

Фрекен Снорк. Сестра Снорка. Предмет юношеской любви и обожания Муми-тролля. Любит цветы, смотреться в зеркало и расчесывать свою челку. Не любит, когда Муми-тролль интересуется другими девочками.

Снусмумрик. Лучший друг Муми-тролля. Да и вообще лучший друг. Пока муми-тролли впадают зимой в спячку, уходит на юг путешествовать. Соответственно, много путешествовал и много знает. Не любит ничем владеть. Живет в палатке. Носит одежду, в которой родился. Играет на губной гармошке.

Снифф. Друг Муми-тролля. Маленькая зверушка, в мультфильме стал побольше :) В отличие от Снусмумрика очень жадный, любит золото. Труслив.

Крошка Мю. Сводная сестра Снусмумрика. Самый маленький обитатель Муми-дома. Однако самый суровый, активный и непоседливый. Отчаянно смела, несмотря на свой размер.

Хемуль. Хемулей в книжках много. Чаще всего это полицейские или сторожа, они любят порядок. Носят юбки, доставшиеся в наследство от теток. Этот Хемуль живет рядом с Муми-троллями и знаменит тем, что собрал все марки на свете. А так как быть владельцем не так увлекательно, как быть коллекционером, переключился на коллекционирование растений.

Туу-тикки. Загадочная дама. Появляется только зимой и живет в купальне Муми-троллей. Любит рыбачить. Имеет интересный взгляд на жизнь.

Морра. Страслая и ужаслая. Самый отрицательный персонаж. Все её боятся. Замораживает все вокруг. Заморозила розовые кусты Муми-мамы. Одинока (хотя, по всей видимости, существуют и другие морры). Однажды, после долгого общения с Муми-троллем, отогрелась.

Хатифнатты. Самые загадочные существа. Не умеют говорить и слышать. Вырастают из семян. В грозу накапливают электричество и бьются током. Собираются большими толпами. Плавают в лодочках. Однажды Муми-папа плавал с ними.

2014-09-07

О деплое MongoDB

Ну давайте про Монгу. Хоть Монга и сверхпопулярна, и её используют даже там, где бы и не стоило, но мне часто задают вопрос: как правильно развернуть кластер на Монге. Вообще-то, чтобы правильно ответить на этот вопрос, достаточно дважды внимательно прочитать официальную документацию. Думаю, еще раз про это, и на русском, не помешает.


В отличие от более других NoSQL в Монге разделены репликация и шардинг. И replication factor определяется не настройками базы или коллекций, а самой конфигурацией кластера. И, соответственно, узлы в кластере играют определенную роль и не равнозначны. Видно, что так сложилось исторически. И жить от этого не легче.

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

Репликация. Когда-то в Монге была мастер-слейв репликация. Но это было настолько давно, что уже не актуально. Теперешняя репликация базируется на понятии репликасета (Replica Set). Репликасет — это набор узлов (точнее процессов mongod), которые реплицируют данные друг на друга (т.е. содержат одинаковый набор данных). Один из этих узлов избирается Primary и все операции записи направляются на него. А он уже реплицирует эти операции (повтором операций из журнала) на другие Secondary узлы.


Если Primary становится недоступным (с точки зрения других узлов репликасета), то устраиваются выборы. И некий новый узел становится Primary. Чтобы избежать неоднозначностей, в выборах должно участвовать большинство (строго больше половины) известных узлов репликасета. А это значит, что узлов должно быть нечетное количество. Если же вам неохота хранить аж три копии данных, когда достаточно двух, можно добавить арбитра (Arbiter). Арбитр, это mongod, запущенный со специальным ключом. Он входит в репликасет, он, как и другие узлы, хранит у себя полную конфигурацию репликасета, он участвует в выборах, но он не хранит реальные данные репликасета и никогда не становится Primary. Такой вот грязный хак.


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

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

С точки зрения клиента подключение к репликасету несколько отличается от подключения к одиночному mongod. Нужно указывать имя репликасета и адрес одного из узлов. И клиент будет открывать подключения ко всем узлам репликасета (разве что кроме арбитров) и сам разбираться, кто там Primary, чтобы именно ему слать команды на запись.

При записи можно указать, какой степени надежности сохранения данных мы хотим достичь: просто послать команду и забыть, дождаться записи в журнал на Primary, дождаться записи данных на диск на Primary, дождаться репликации на один, два, большинство, конкретное число Secondary. Это называется Write Concern и похоже на соответствующие опции Кассандры. Помните, что ожидание репликации сильно задержит выполнение операции записи. Впрочем, ожидание сброса на диск тоже может быть долгим, ибо в Монге это делается по таймеру.

При чтении можно потребовать читать только с Primary, предпочтительно с Primary, только с Secondary, предпочтительно с Secondary или с ближайшего (с наименьшими сетевыми задержками) узла. Это называется Read Preference. Помните, что при чтении с Primary мы получаем строгую целостность, чтение сразу после записи прочтет измененные данные, ибо эти данные находятся на одной машине, а модификация их происходит через блокировку. А вот при чтении с Secondary будет достигнута только целостность в конечном счете (eventual consistency), когда-нибудь, после репликации, читаемые данные совпадут с записанными.

Репликасет предназначен для увеличения надежности хранения данных и обеспечения отказоустойчивости кластера. Можно также увеличить производительность кластера на чтение, если читать с Secondary, за счет eventual consistency. Если же нужно масштабировать производительность записи, а также хранить данных больше, чем уместится на одном узле, нужен шардинг (Sharding).

В Монге есть автоматический шардинг. Для этого нужно собрать кластер с соответствующей конфигурацией, включить шардинг для базы данных, указать ключ шардинга для коллекции. И Монга самостоятельно размажет ваши данные ровным слоем между шардами. Все множество значений ключей шардинга (или хэшей ключей) разбивается на диапазоны. Для каждого диапазона назначается шард, в котором данные из этого диапазона будут хранится. Например, от минус бесконечности до "N" — в шарде №1, от "N" до плюс бесконечности — в шарде №2.

Шардами в Монге могут быть либо отдельные инстансы mongod, либо репликасеты. Первый вариант рекомендуется только для разработки, ибо потеря любого узла приводит к потере части данных. А вот второй вариант — шарды из репликасетов — это и есть настоящий большой промышленный кластер Монги. Получается, что сначала происходит размазывание данных по шардам, а затем реплицирование между членами репликасета.


Иногда, когда данных не сильно много, но очень нужна хорошая производительность на запись, можно совместить на одном узле Primary и Secondary сервера разных шардов, чтобы и запись распределить между узлами, и несколько копий данных иметь. Например, так:
Шард №1 Шард №2 Шард №3
Узел №1 Primary Arbiter Secondary
Узел №2 Secondary Primary Arbiter
Узел №3 Arbiter Secondary Primary
Впрочем, это не есть официально рекомендуемая конфигурация, так что решайте сами.

Кроме шардов из репликасетов, нужна еще пара компонент. Роутер запросов под названием mongos (Mongo Switch) — процесс, через который должны направлятся все запросы к шардированному кластеру. Именно он выясняет, на каком шарде находится (или должен находится) нужный документ, и перенаправляет туда запросы. Также он занимается миграцией и балансировкой шардов. Рекомендуется запускать mongos на каждом клиенте, т.е. на том узле, где у вас запущено приложение, использующее Монгу. Т.к. mongos ничего не хранит на диске и лишь немножко кушает память и ЦПУ, это вполне возможно. Для клиента подключение к mongos выглядит как подключение к одиночному mongod. Т.е. с точки зрения приложения, что есть шардинг, что его нет — почти одинаково.

Еще нужны конфиг сервера (Config Servers). Это обычные mongod, которые хранят метаданные о кластере. Это те самые диапазоны ключей шардинга, как они разбросаны по шардам. Объем метаданных — мизерный по сравнению с реальными данными. Запись в конфиг сервера происходит только при изменении конфигурации: добавлении или удалении новых шардов или перебалансировке кластера. В продукшене рекомендуется запускать три конфиг сервера для надежности (это не репликасет, это три отдельных сервера, синхронизацией между ними занимается mongos). Для карманного тестирования достаточно одного конфиг сервера.

Подытожим. Есть узлы с клиентским приложением. На этих же узлах должен быть запущен mongos. Клиент подключается к mongos на локалхосте. mongos подключается к шардам и конфиг серверам. Три конфиг сервера развернуты на трех разных узлах где-то в сторонке. Шарды представляют собой репликасеты. В каждом шарде/репликасете должно быть несколько узлов для хранения данных, в зависимости от того, сколько копий данных вы хотите хранить. Эти узлы сами выберут между собой, кто из них Primary. Общее число узлов в шарде/репликасете должно быть нечетным. Если у вас четный replication factor, нужно в каждый шард/репликасет добавить арбитра. Арбитров можно расположить где-нибудь сбоку или же раскидать по узлам с данными, важно только, чтобы он не находился на одном узле с другими серверами своего репликасета.


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

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