что такое vendor в андроиде
990x.top
Простой компьютерный блог для души)
Папка vendor — что это?
Приветствую. Данный материал расскажет об одном каталоге, который можно встретить на персональном компьютере/мобильном устройстве.
Вообще vendor — слово, пришло с английского языка, имеет несколько значений: продавец, в компьютерном мире — поставщик железа. Важно понимать, что вендор в некотором смысле это компания/производитель устройств под собственным брендом. Например Samsung — вендор.
Папка vendor на Android
Содержит файлы, который были созданы еще при изготовлении устройства на заводе. Данные файлы — микропрограммы некоторых компонентов, например модуля Wi-Fi, Bluetooth.
Удалять содержимое или саму папку — нежелательно. При желании удалить — сперва создайте резервную копию OS Android.
Каталог операционной системы Андроид (создатель Google).
Папка vendor в Lavarel
Хранит внешние библиотеки, функции которых могут использоваться при написании сайтов, веб-приложений. Некоторые пользователи сообщают, что библиотеки не стоит подключать к проекту.
Lavarel — это некий движок, на основе которого создают современные веб-сайты. Чтобы использовать движок нужно знать язык программирования PHP, быть не совсем начинающем программистом.
Директория проекта. При разработке веб-сайтов или программного обеспечения используют среду разработки (IDE), где собственно и можно заметить данный каталог.
Заключение
Vendor Identifier — что это за программа на Андроид?
Приветствую друзья, сегодня у нас тема — приложение Vendor Identifier на Android. Моя задача — узнать что это за прога.. для чего нужна.. может это вообще вирус? Такс ребята, не будем гадать, а начинаем разбираться!
Vendor Identifier — что это такое?
Начал копаться в интернете. Инфы ребята не так уж и много.. но кое что все таки выяснил:
Vendor Identifier — непонятное приложение, предположительно показывает рекламу. Кроме этого может быть еще одно — Incartech, скорее всего также рекламное.
Один пользователь удалил Vendor Identifier, пишет что проблем нет, реклама пропала. Однако он также удалил и Incartech. Что самое интересное.. чел пробовал все — чистить систему антивирусами, всякими чистилками, но эффекта ноль. Также пробовал.. перепрошивать телефон. Но в итоге реклама все равно была. Да, такое спокойно может быть — рекламное приложение идет встроенным в прошивку, особенно часто явление встречается на китайских телефонах.
То есть можно сделать вывод, что название спецом сделано так, чтобы вводить нас в заблуждение. Чтобы подумали что норм приложение и опасности не представляет.. ну и не думали удалять..
Ребята, инфы нет вообще больше. Я прочесал интернет — ничего не нашел.
Что делать?
Я вижу два варианта:
В титаниуме просто выбираете приложение, например cLock 2.2.5, нажимаете по нему:
И потом уже будет кнопка заморозки приложения:
Если будете проверять антивирусом, то советую использовать известный, например Касперский, Доктор Веб, Нод.
Также оч советую обратится на форум 4PDA. Если вы там найдете свою модель телефона — то напишите в теме, просто опишите свою проблему. Если вашей модели нет — напишите в теме похожей. Могут помочь, не вы одни с этой проблемой.
Хотя вот пишут что лучший антивирус это Antiy AVL, он обнаруживает до 99.7% угроз в реальном времени. Насколько правда — не знаю, но название антивируса не особо известное.. по крайней мере мне..
Так, стоп, вот узнал что есть такое приложение как AirPush Detector, которое сканирует все приложения на наличие рекламы. Стоит попробовать.
Заключение
К сожалению толком ничего узнать не получилось, потому что инфы тупо нет. Но вывод можно сделать такой:
В общем ребята, на этом все. Сори, что мало написал, но в интернете реально инфы оч мало. Удачи вам и добра!
Хватит это терпеть: вендорский Android, который портит классные смартфоны
Классическая история: вы покупаете флагманский смартфон и поначалу не можете ему нарадоваться. Приложения открываются моментально, PUBG Mobile летает на максимальных настройках, рабочий стол изумляет плавностью и удобством. Но проходит полгода и выясняется, что гаджет не особо и шустрый, а интерфейс тормозит. А ведь крупных обновлений ещё не было, да и вы вроде не мусорили: установили мессенджеры, соцсети, пару нужных игр и утилит. Кого благодарить за столь разительную перемену? Конечно же, вендора и его «замечательную» фирменную оболочку.
Понятие «чистый Android» знакомо многим: одни уже радуются стоковой ОС на своём гаджете, другие только планируют перепрошиться. Едва ли кто-то будет спорить: давно прошли те времена, когда фирменные оболочки были заметно функциональнее базового «зелёного робота». Разумеется, раньше дополнительные возможности вроде режима разделённого экрана или съёмки в RAW-формате стоили того, чтобы терпеть тормоза и прочие неудобства. Сегодня же в этом нет необходимости.
Матчасть
Чистая версия системы имеет две разновидности: для разработчиков и пользователей. В первом случае речь про AOSP — платформу с открытым исходным кодом, который может свободно использовать любая компания для собственной прошивки. Чистый Android для пользователей — это готовое решение от Google: с единым набором настроек, предустановленных приложений и домашним экраном Pixel Launcher.
Pixel Launcher на Android 8.1
Альтернативы стандартному «роботу» появились уже для версии 1.6 Donut. Впрочем, более ранние варианты ОС устанавливались разве что на HTC Dream, если говорить о вышедших на рынок устройствах. Вендоры практически с первых дней жизни Android старались сделать его более красивым и удобным. Они облагораживали неказистый стоковый интерфейс (что само по себе заметно загружало оперативную память). И добавляли элементы вроде быстрых переключателей в шторке уведомлений, без которых мы сегодня не представляем себе смартфон. Так нишевая на тот момент платформа обретала человеческое лицо и привлекала массового потребителя.
Год за годом поисковой гигант собирал наиболее полезные функции чужих прошивок и внедрял в собственные. Окончательно дружелюбным к пользователю Android стал, пожалуй, в версии 4.0 с дизайном Holo. А современный вид — с незначительными отличиями — «зелёная» ОС обрела с приходом Material Design в версии 5.0. И чем активнее Google шлифовала свою платформу, тем очевиднее становился факт, что вендорские «обёртки» загружают процессор и ОЗУ.
Стандарт от Google — в массы
Необходимость в фирменных оболочках сегодня попросту отпала. Конечно, многие крупные производители продолжают выпускать аппараты с собственными прошивками и едва ли откажутся от такой практики. Ведь в противном случае выйдет, что годы разработки и миллионы долларов потрачены впустую. Несмотря на это, чистая система вовсю набирает обороты. А Google под это дело продвигает собственный стандарт Android One, который сегодня присутствует уже в пятом поколении устройств.
Напомним, что Android One — это не вариация ОС, а именно всемирный стандарт для создателей смартфонов. Потребитель получает гаджет с AOSP и Pixel Launcher. Вмешательство вендора ограничено минимальными визуальными изменениями. За структуру системы, оптимизацию и обновления — начиная с Android 8.0 Oreo — отвечает Google. Из софта производитель волен добавлять лишь приложения для железа (камеры в первую очередь, например, Pro-Camera в смартфонах Nokia) и для вывода пользователя на техподдержку (например, Nokia Mobile Care).
Изначально Android One был ориентирован на бюджетный сегмент, где каждое лишнее приложение и украшательство бьёт по общей производительности. Конечно, современные «слабые» процессоры уже не так беспомощны, как в прошлые годы, и отлично работают с хорошо оптимизированным софтом. Да и последние версии мобильной ОС, в сравнении с прародителями, тоже шагнули далеко вперёд.
Логично, что в первую очередь к инициативе Google присоединились лишь несколько индийских вендоров, выпускающих максимально дешёвые устройства. Сегодня же, в пятом поколении, стандарт стремительно набирает обороты и насчитывает уже 33 аппарата, включая флагманские. Например, в 2017 году компания HMD Global вернула на рынок смартфоны бренда Nokia и впервые оснастила их чистым Android актуальной версии. А в 2018-м Nokia официально присоединилась к стандарту Android One с новыми гаджетами 3.1, 5.1, 6.1, 7 Plus и 8 Sirocco.
Nokia 7 Plus на Android 8.0
Почему фирменные прошивки — зло
Если с бюджетными моделями всё понятно, то зачем отказываться от дополнительных «наворотов» на средних и флагманских устройствах? К чему OEM-производителям менять проверенный временем подход и довольствоваться базовой функциональностью от Google?
Вендоры часто загружают в аппараты с собственными «обёртками» большое количество приложений. Конечно, это могут быть нужные, полезные, даже в каких-то случаях незаменимые программы, но вот беда — покупателя никто не спросил. Может, вместо какого-нибудь диспетчера устройств ему важнее загрузить побольше музыки, фильмов и игр на свой и без того не резиновый накопитель. Без root-прав можно разве что иконки с рабочего стола в отдельную папку спрятать, да и то не всегда. А получение «рута» зачастую лишает официальной гарантии, поскольку его нельзя получить без разблокировки загрузчика. Что, в свою очередь, может даже «окирпичить» смартфон или сделать его «калекой», отключив навсегда систему шифрования накопителя или поддержку фирменной системы платежей через NFC.
Не всё гладко и с обновлениями до новой версии ОС. Логика проста: чем больше «отсебятины», тем сложнее адаптировать прошивку. В прошлом году Google анонсировала Project Treble для Android 8.0 — новый стандарт, который чётко разграничивает низкоуровневые драйверы ОС от «наворотов». По идее, это должно позволить производителям обновляться намного быстрее, но пока что воз и ныне там.
Распределение версий Android по состоянию на 23 июля 2018 года
А ведь актуальные версии — это не только полезные функции и свежий дизайн. Там вшиты новейшие политики безопасности, защищающие устройства от вирусов и прочей нечисти, которой полон интернет. Но пользователи многих Android-устройств про это ничего не знают: вендоры не спешат — если не сказать грубее — их обновлять. В то время как гаджеты, участвующие в программе Android One, не говоря уже о гугловских «пикселях», оперативно получают апдейты. Все смартфоны Nokia, к примеру, в течение трёх лет получают ежемесячные патчи безопасности, а также регулярные общие обновления системы (на протяжении как минимум двух лет с момента выхода аппарата).
Плюсы и минусы чистого Android
Конечно, можно сколько угодно говорить о прошивках, портящих классные смартфоны, но где факты? Что ж, вот несколько доводов за и против.
Стоковая ОС работает быстрее. Вся система за много лет оптимизирована авторами. Соответственно, работать она должна заметно шустрее, в чём мы благополучно убедились в прошлом году. Расход памяти тоже снижается: фирменная оболочка и её приложения гораздо чаще обращаются к ОЗУ.
Больше свободного места на накопителе. Вендорская прошивка со всеми её «бантиками и рюшечками» съедает сотни мегабайт (если не свыше гигабайта). А ведь их можно заполнить, к примеру, музыкой или фотографиями.
Выверенный дизайн. Начиная с версии 5.0 Lollipop, Android живёт в среде Material Design — визуальном языке, который выражает функциональность через минимализм и понятные абстракции. А уж новейший Oreo и вовсе не стыдно поставить даже на самый навороченный флагман Nokia.
Все службы Google на своём месте. Некоторые производители любят менять традиционные приложения и службы Google на собственные аналоги. И если в родной стране местные версии поиска или маркета и работают, то нам от этого нет никакой пользы.
Обновления гарантированы, причём без задержек. Пользователи стоковой ОС всегда получают апдейты первыми. Pixel 2 XL собственной разработки Google или смартфон Nokia — разница во времени между их обновлениями до актуальной версии будет минимальной. В то время как создатели кастомных прошивок часто даже не сдерживают обещаний по запланированным патчам.
Получается, смысла в фирменных оболочках нет? Как ни парадоксально, но и они могут кое-что предложить.
В чистом Android нет многих полезных настроек. Действительно, часто вендоры предлагают возможности, от которых Google по тем или иным причинам отказалась. Клонирование приложений и рабочих пространств, тонкие настройки дисплея, быстрая смена тем и анимаций, изменение сетки иконок, игровой и детский режимы и так далее. Но будем честны: далеко не все эти функции востребованы широкими массами. Да и многие из них доступны в Google Play в виде утилит.
Чего ждать завтра?
Оправдывать необходимость собственных прошивок OEM-производителям всё труднее. Соответственно, расходы на разработку специфического ПО, которое вообще-то уже придумано, написано и внедрено на уровне ОС, выглядят всё менее разумными. Мы можем смело предположить, что базовый Android со временем существенно подвинет вендорские решения. Вероятно, он вытеснит их так же, как в своё время произошло с Bada, Tizen и SailfishOS. Если из них кто и остался в живых, то лишь в качестве нишевой ОС для носимых аксессуаров и телевизоров.
Пример использования Tizen в современных устройствах
Конечно, если Google всё-таки доведёт до ума Project Treble, то существенно поддержит вендоров: они смогут быстрее обновляться до новой версии ОС, несмотря на количество собственного тюнинга. Но это снимет только одно из пяти возражений против фирменных интерфейсов. А значит, смышлёный пользователь всё равно будет голосовать рублём — или любой другой валютой — за более привлекательный «чистый» аппарат, который к тому же и дешевле.
А как вы считаете, есть ли сегодня потребность в вендорских прошивках? Или им давно пора на покой? Поделитесь своим мнением в комментариях.
Как переразбить разделы памяти Android и не получить кирпич: пошаговый мануал для чайников.
Напишу здесь, может кому пригодится.
Этот способ приведён для справки и не приведёт к желаемому результату на всех без исключения устройствах. Так что прошу принять к сведению, но не следовать бездумно. И конечно же все риски за возможные негативные последствия вы несёте сами.
Установку драйверов и ADB для своих устройств вам придётся искать самостоятельно. Также не освещаются нюансы переноса разделов из чипа внутренней памяти на microSD карты и наоборот.
Значится порядок действий: загрузить на планшете кастомный рекавери, открыть в Windows Power Shell (или командной строке) папку с adb.exe, подключить кабелем планшет к ПК, желательно прямо к мат. плате, а не через разъём на лицевой панели, а то может не видеть ваше устройство.
«.\» не нужно писать в простой командной строке, только в Power Shell.
Далее уже в оболочке:
Смотрим есть ли у нас этот модуль предустановленный (у меня не было) в результате:
# [6nls
ls
boot init.recovery.service.rc selinux_version
cache init.recovery.usb.rc sepolicy
charger license service_contexts
data oem sideload
default.prop proc sys
dev property_contexts system
etc recovery tmp
file_contexts res twres
fstab.flo root ueventd.flo.rc
init sbin ueventd.rc
init.rc sdcard usb-otg
init.recovery.hlthchrg.rc seapp_contexts vendor
Нету, значит нужно поставить. Качаем этот файл, закидываем его распакованным в папку к adb.exe.
Выходим из оболочки:
ls
PARTED init.recovery.service.rc sepolicy
boot init.recovery.usb.rc service_contexts
cache license sideload
charger oem sys
data proc system
default.prop property_contexts tmp
dev recovery twres
etc res ueventd.flo.rc
file_contexts root ueventd.rc
fstab.flo sbin usb-otg
init sdcard vendor
init.rc seapp_contexts
init.recovery.hlthchrg.rc selinux_version
Всё, можно редактировать разделы памяти.
Я получил следующее:
GNU Parted 1.8.8.1.179-aef3
Using /dev/block/mmcblk0
Welcome to GNU Parted! Type ‘help’ to view a list of commands.
После этого команда:
И получим перечень разделов памяти:
Model: MMC HBG4e (sd/mmc)
Disk /dev/block/mmcblk0: 31.3GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 67.1MB 157MB 89.6MB fat16 radio
2 201MB 204MB 3146kB modemst1
3 204MB 208MB 3146kB modemst2
4 268MB 284MB 15.4MB ext4 persist
5 336MB 336MB 799kB m9kefs1
6 336MB 337MB 799kB m9kefs2
7 403MB 403MB 799kB m9kefs3
8 403MB 407MB 3146kB fsg
9 470MB 471MB 1536kB sbl1
10 471MB 473MB 1536kB sbl2
11 473MB 475MB 2097kB sbl3
12 475MB 480MB 5243kB aboot
13 480MB 481MB 524kB rpm
14 537MB 554MB 16.8MB boot
15 604MB 605MB 524kB tz
16 605MB 605MB 1024B pad
17 605MB 606MB 1536kB sbl2b
18 606MB 608MB 2097kB sbl3b
19 608MB 613MB 5243kB abootb
20 613MB 614MB 524kB rpmb
21 614MB 614MB 524kB tzb
22 671MB 1552MB 881MB ext2 system
23 1552MB 2139MB 587MB ext4 cache
24 2147MB 2149MB 1049kB misc
25 2215MB 2225MB 10.5MB recovery
26 2282MB 2282MB 8192B DDR
27 2282MB 2282MB 8192B ssd
28 2282MB 2282MB 1024B m9kefsc
29 2349MB 2349MB 32.8kB metadata
30 2416MB 31.3GB 28.9GB ext4 userdata
Переведём отображение размеров с байтов на сектора, в одном мегабайте 2048 таких секторов:
Model: MMC HBG4e (sd/mmc)
Disk /dev/block/mmcblk0: 61079552s
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 131072s 306143s 175072s fat16 radio
2 393216s 399359s 6144s modemst1
3 399360s 405503s 6144s modemst2
4 524288s 554287s 30000s ext4 persist
5 655360s 656919s 1560s m9kefs1
6 656920s 658479s 1560s m9kefs2
7 786432s 787991s 1560s m9kefs3
8 787992s 794135s 6144s fsg
9 917504s 920503s 3000s sbl1
10 920504s 923503s 3000s sbl2
11 923504s 927599s 4096s sbl3
12 927600s 937839s 10240s aboot
13 937840s 938863s 1024s rpm
14 1048576s 1081343s 32768s boot
15 1179648s 1180671s 1024s tz
16 1180672s 1180673s 2s pad
17 1180674s 1183673s 3000s sbl2b
18 1183674s 1187769s 4096s sbl3b
19 1187770s 1198009s 10240s abootb
20 1198010s 1199033s 1024s rpmb
21 1199034s 1200057s 1024s tzb
22 1310720s 3031039s 1720320s ext2 system
23 3031040s 4177919s 1146880s ext4 cache
24 4194304s 4196351s 2048s misc
25 4325376s 4345855s 20480s recovery
26 4456448s 4456463s 16s DDR
27 4456464s 4456479s 16s ssd
28 4456480s 4456481s 2s m9kefsc
29 4587520s 4587583s 64s metadata
30 4718592s 61079518s 56360927s ext4 userdata
И мы видим, что system можно расширить «вверх» до tzb, так как память там не размечена и «вниз», отщипнув часть раздела recovery.
Создаём новые с границами в нужных нам секторах и присваиваем им старые названия:
mkpart 22 1200058 3317759
mkpart 23 3317760 4177919
name 22 system
name 23 cache
Успех, результат (показывает не в секторах, так как я отсоединял планшет перед этим по незнанию, разделы 22 и 23 ещё не отформатированы):
Model: MMC HBG4e (sd/mmc)
Disk /dev/block/mmcblk0: 31.3GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 67.1MB 157MB 89.6MB fat16 radio
2 201MB 204MB 3146kB modemst1
3 204MB 208MB 3146kB modemst2
4 268MB 284MB 15.4MB ext4 persist
5 336MB 336MB 799kB m9kefs1
6 336MB 337MB 799kB m9kefs2
7 403MB 403MB 799kB m9kefs3
8 403MB 407MB 3146kB fsg
9 470MB 471MB 1536kB sbl1
10 471MB 473MB 1536kB sbl2
11 473MB 475MB 2097kB sbl3
12 475MB 480MB 5243kB aboot
13 480MB 481MB 524kB rpm
14 537MB 554MB 16.8MB boot
15 604MB 605MB 524kB tz
16 605MB 605MB 1024B pad
17 605MB 606MB 1536kB sbl2b
18 606MB 608MB 2097kB sbl3b
19 608MB 613MB 5243kB abootb
20 613MB 614MB 524kB rpmb
21 614MB 614MB 524kB tzb
22 614MB 1699MB 1084MB system
23 1699MB 2139MB 440MB cache
24 2147MB 2149MB 1049kB misc
25 2215MB 2225MB 10.5MB recovery
26 2282MB 2282MB 8192B DDR
27 2282MB 2282MB 8192B ssd
28 2282MB 2282MB 1024B m9kefsc
29 2349MB 2349MB 32.8kB metadata
30 2416MB 31.3GB 28.9GB ext4 userdata
Далее идём в рекавери на примере TWRP: wipe-advanced wipe-repair or change file system, где по очереди форматируете system в ext2, а cache в ext4.
Таким образом я смог установить GApps pico и в системном разделе осталось около 40 мб свободными.
Текст мой, размещён также на форуме 4pda в соответствующей теме.
Как работает Android, часть 4
Всем привет! Мы нашли время продолжить серию статей про внутреннее устройство Android. В этой статье я расскажу о процессе загрузки Android, о содержимом файловой системы, о том, как хранятся данные пользователя и приложений, о root-доступе, о переносимости сборок Android и о проблеме фрагментации.
Пакеты
Как я уже говорил раньше, архитектура Android построена вокруг приложений. Именно приложения играют ключевую роль в устройстве многих частей системы, именно для гармоничного взаимодействия приложений выстроена модель activity и intent’ов, именно на изоляции приложений основана модель безопасности Android. И если оркестрированием взаимодействия компонентов приложений занимается activity manager, то за установку, обновление и управление правами приложений отвечает package manager (пакетный менеджер — в shell его можно вызвать командой pm ).
Каждый APK при сборке должен быть подписан разработчиком с использованием цифровой подписи. Android проверяет наличие этой подписи при установке приложения, а при обновлении уже установленного приложения дополнительно сравнивает публичные ключи, которыми подписаны старая и новая версия; они должны совпадать, что гарантирует, что новая версия была создана тем же разработчиком, что и старая. (Если бы этой проверки не было, злоумышленник мог бы создать пакет с таким же именем, как и у существующего приложения, убедить пользователя установить его, «обновляя» приложение, и получить доступ к данным этого приложения.)
Само обновление пакета представляет собой установку его новой версии вместо старой с сохранением данных и полученных от пользователя разрешений. Можно и «откатывать» (downgrade) приложения до более старых версий, но при этом по умолчанию Android стирает сохранённые новой версией данные, поскольку старая версия может быть не способна работать с форматами данных, которые использует новая версия.
Как я уже говорил, обычно код каждого приложения выполняется под собственным Unix-пользователем (UID), что и обеспечивает их взаимную изоляцию. Несколько приложений могут явно попросить Android использовать для них общий UID, что позволит им получать прямой доступ к файлам друг друга и даже, при желании, запускаться в одном процессе.
Хотя обычно одному пакету соответствует один файл APK, Android поддерживает пакеты, состоящие из нескольких APK (это называется раздельными APK, или split APK). Это лежит в основе таких «магических» возможностей Android, как динамическая загрузка дополнительных модулей приложения (dynamic feature modules) и Instant Run в Android Studio (автоматическое обновление кода запущенного приложения без его полной переустановки и, во многих случаях, даже без перезапуска).
Файловая система
Устройство файловой системы — один из самых важных и интересных вопросов в архитектуре операционной системы, и устройство файловой системы в Android — не исключение.
Интерес представляет, во-первых, то, какие файловые системы используются, то есть в каком именно формате содержимое файлов сохраняется на условный диск (в случае Android это обычно flash-память и SD-карты) и как обеспечивается поддержка этого формата со стороны ядра системы. Ядро Linux, используемое в Android, в той или иной степени поддерживает большое количество самых разных файловых систем — от используемых в Windows FAT и NTFS и используемых в Darwin печально известной HFS+ и современной APFS — до сетевой 9pfs из Plan 9. Есть и много «родных» для Linux файловых систем — например, Btrfs и семейство ext.
Стандартом де-факто для Linux уже долгое время является ext4, используемая по умолчанию большинством популярных дистрибутивов Linux. Поэтому нет ничего неожиданного в том, что именно она и используется в Android. В некоторых сборках (и некоторыми энтузиастами) также используется F2FS (Flash-Friendly File System), оптимизированная специально для flash-памяти (впрочем, с её преимуществами всё не так однозначно).
Во-вторых, интерес представляет так называемый filesystem layout — расположение системных и пользовательских папок и файлов в файловой системе. Filesystem layout в «обычном Linux» заслуживает более подробного описания (которое можно найти, например, по этой ссылке); я упомяну здесь только несколько наиболее важных директорий:
Android использует похожий, но заметно отличающийся filesystem layout. Вот несколько самых важных из его частей:
Суффикс в названии папок приложений — 16 случайных байт, закодированных в Base64. Использование такого суффикса не позволяет другим приложениям «угадать» путь к приложению, о существовании которого им знать не следует. В принципе, список установленных на устройстве приложений и путей к ним не является секретом — его можно получить через стандартные API — но в некоторых случаях (а именно, для Instant apps) на доступ к этим данным накладываются ограничения.
Для хранения изменяемых данных каждому приложению выделяется папка в /data/data (например, /data/data/com.google.android.youtube для YouTube). Доступ к этой папке есть только у самого приложения — то есть только у UID, под которым запускается это приложение (если приложение использует несколько UID, или несколько приложений используют общий UID, всё может быть сложнее). В этой папке приложения сохраняют настройки, кэш (в подпапках shared_prefs и cache соответственно) и любые другие нужные им данные:
Система знает о существовании папки cache и может очищать её самостоятельно при нехватке места. При удалении приложения вся папка этого приложения полностью удаляется, и приложение не оставляет за собой следов. Альтернативно, и то, и другое пользователь может явно сделать в настройках:
Это выделяемое каждому приложению хранилище данных называется внутренним хранилищем (internal storage).
Кроме того, в Android есть и другой тип хранилища — так называемое внешнее хранилище (external storage — это название отражает изначальную задумку о том, что внешнее хранилище должно было располагаться на вставляемой в телефон внешней SD-карте). По сути, внешнее хранилище играет роль домашней папки пользователя — именно там располагаются такие папки, как Documents, Download, Music и Pictures, именно внешнее хранилище открывают файловые менеджеры в качестве папки по умолчанию, именно к содержимому внешнего хранилища Android позволяет получить доступ компьютеру при подключении по кабелю.
Как я упомянул выше, исходно предполагалось, что внешнее хранилище действительно будет располагаться на внешней SD-карте, поскольку в то время объём SD-карт значительно превышал объём встраиваемой в телефоны памяти (в том же самом HTC Dream её было лишь 256 мегабайта, из которых на раздел data выделялось порядка 90 мегабайт). С тех пор многие условия изменились; в современных телефонах часто нет слота для SD-карты, зато устанавливается огромное по мобильным меркам количество встроенной памяти (например, в Samsung Galaxy Note 9 её может быть до 512 гигабайт).
С другой стороны, у многих устройств всё-таки есть слот для SD-карты. Вставленную в Android-устройство SD-карту можно использовать как обычный внешний диск (не превращая её во внутреннее или внешнее хранилище системы) — сохранять на неё файлы, открывать хранящиеся на ней файлы, использовать её для перенесения файлов на другие устройства и т.п. Кроме того, Android позволяет «заимствовать» SD-карту и разместить внутреннее и внешнее хранилище на ней (это называется заимствованным хранилищем — adopted storage). При этом система переформатирует SD-карту и шифрует её содержимое — хранящиеся на ней данные невозможно прочесть, подключив её к другому устройству.
Подробнее почитать про всё это можно, например, вот в этом посте и в официальной документации для разработчиков приложений и для создателей сборок Android.
Загрузка
Традиционный подход к безопасности компьютерных систем ограничивается тем, чтобы защищать систему от программных атак. Считается, что если у злоумышленника есть физический доступ к компьютеру, игра уже проиграна: он может получить полный доступ к любым хранящимся на нём данным. Для этого ему достаточно, например, запустить на этом компьютере произвольную контролируемую им операционную систему, позволяющую ему обойти любые накладываемые «основной» системой ограничения прав, или напрямую подключить диск с данными к другому устройству. При желании, злоумышленник может оставить компьютер в работоспособном состоянии, но пропатчить установленную на нём систему, установить произвольные бэкдоры, кейлоггеры и т.п.
Именно на защиту от программных атак ориентирована модель ограничения прав пользователей в Unix (и основанная на ней технология app sandbox в Android); само по себе ограничение прав в Unix никак не защищает систему от пользователя, пробравшегося в серверную и получившего физический доступ к компьютеру. И если серьёзные многопользовательские сервера можно и нужно охранять от неавторизованного физического доступа, к персональным компьютерам — а тем более мобильным устройствам — такой подход просто неприменим.
Пытаться улучшать ситуацию с защитой от злоумышленника, получившего физический доступ к устройству, можно по двум направлениям:
Именно с этими двумя направлениями защиты связана модель безопасной загрузки в Android.
Verified Boot
Процесс загрузки Android построен так, что он, с одной стороны, не позволяет злоумышленникам загружать на устройстве произвольную ОС, с другой стороны, может позволять пользователям устанавливать кастомизированные сборки Android (и другие системы).
Прежде всего, Android-устройства, в отличие от «десктопных» компьютеров, обычно не позволяют пользователю (или злоумышленнику) произвести загрузку со внешнего носителя; вместо этого сразу запускается установленный на устройстве bootloader (загрузчик). Bootloader — это относительно простая программа, в задачи которой (при загрузке в обыкновенном режиме) входят:
Flashing, unlocking, fastboot и recovery
Кроме того, bootloader поддерживает дополнительную функциональность для обновления и переустановки системы.
Во-первых, это возможность загрузить вместо основной системы (Android) специальную минимальную систему, называемую recovery. Версия recovery, устанавливаемая на большинство Android-устройств по умолчанию, очень минималистична и поддерживает только установку обновлений системы в автоматическом режиме, но многие энтузиасты Android устанавливают кастомную recovery.
Это делается путём использования второй «фичи» bootloader’а, направленной на обновление и переустановку системы — поддержки перезаписи (flashing) содержимого и структуры разделов по командам с подсоединённого по кабелю компьютера. Для этого bootloader способен загружаться в ещё один специальный режим, который называют fastboot mode (или иногда просто bootloader mode), поскольку обычно для общения между компьютером и bootloader’ом в этом режиме используется протокол fastboot (и соответствующий ему инструмент fastboot из Android SDK со стороны компьютера).
Некоторые реализации bootloader’а используют другие протоколы. В основном это касается устройств, выпускаемых компанией Samsung, где специальная реализация bootloader’a (Loke) общается с компьютером по собственному проприетарному протоколу (Odin). Для работы с Odin со стороны компьютера можно использовать либо реализацию от самих Samsung (которая тоже называется Odin), либо свободную реализацию под названием Heimdall.
Конкретные детали зависят от реализации bootloader’а (то есть различаются в зависимости от производителя устройства), но во многих случаях установка recovery и сборок Android, подписанных ключом производителя устройства, просто работает без дополнительных сложностей:
Таким образом можно вручную обновлять систему; а вот установить более старую версию не получится: функция, известная как защита от отката, не позволит bootloader’у загрузить более старую версию Android, чем была загружена в прошлый раз, даже если она подписана ключом производителя, поскольку загрузка старых версий открывает дорогу к использованию опубликованных уязвимостей, которые исправлены в более новых версиях.
Кроме того, многие устройства поддерживают разблокировку bootloader’а (unlocking the bootloader, также известную как OEM unlock) — отключение проверки bootloader’ом подписи системы и recovery, что позволяет устанавливать произвольные сборки того и другого (у части производителей это аннулирует гарантию). Именно так обычно устанавливаются такие популярные дистрибутивы Android, как LineageOS (бывший CyanogenMod), Paranoid Android, AOKP, OmniROM и другие.
Поскольку разблокировка bootloader’а всё-таки позволяет загрузить на устройстве собственную версию системы, в целях безопасности при разблокировке все пользовательские данные (с раздела data) принудительно удаляются. Если систему переустанавливает сам пользователь, а не злоумышленник, после переустановки он может восстановить свои данные из бэкапа (например, из облачного бэкапа на серверах Google или из бэкапа на внешнем носителе), если злоумышленник — он получит работающую систему, но не сможет украсть данные владельца устройства.
После установки предпочитаемых сборок recovery и системы bootloader стоит заблокировать обратно, чтобы снова защитить свои данные в случае попадания устройства в руки злоумышленников.
Для разблокировки bootloader’а может также потребоваться дополнительно разрешить её из настроек системы:
Популярная сторонняя recovery, которую устанавливают большинство «флешаголиков» (flashaholics) — TWRP (Team Win Recovery Project). Она содержит тач-интерфейс и множество продвинутых «фич», в том числе возможность устанавливать части системы из сборок в виде zip-архивов, встроенную поддержку бэкапов и даже полноценный эмулятор терминала с виртуальной клавиатурой:
Шифрование диска
Современные версии Android используют пофайловое шифрование данных (file-based encryption). Этот механизм основан на встроенной в ext4 поддержке шифрования, реализованной в ядре Linux (fscrypt), и позволяет системе зашифровывать различные части файловой системы различными ключами.
По умолчанию система шифрует большинство данных пользователя, расположенных на разделе data, с помощью ключа, который создаётся на основе пароля пользователя и не сохраняется на диск (credential encrypted storage). Это означает, что при загрузке система должна попросить пользователя ввести свой пароль, чтобы вычислить с его помощью ключ для расшифровки данных. Именно поэтому первый раз после включения устройства пользователя встречает требование ввести полный пароль или графический ключ, а не просто пройти аутентификацию, приложив палец к сканеру отпечатков.
В дополнение к credential encrypted storage в Android также используется device encrypted storage — шифрование ключом на основе данных, которые хранятся на устройстве (в том числе в Trusted Execution Environment). Файлы, зашифрованные таким образом, система может расшифровать до того, как пользователь введёт пароль. Это лежит в основе функции, известной как Direct Boot: система способна загружаться в некоторое работоспособное состояние и без ввода пароля; при этом приложения могут явно попросить систему сохранить (наименее приватную) часть своих данных в device encrypted storage, что позволяет им начинать выполнять свои базовые функции, не дожидаясь полной разблокировки устройства. Например, Direct Boot позволяет будильнику срабатывать и до первого ввода пароля, что особенно полезно, если устройство непредвиденно перезагружается ночью из-за временного отключения питания или сбоя системы.
Так называемый root-доступ — это возможность выполнять код от имени «пользователя root» (UID 0, также известного как суперпользователь). Напомню, что root — это специально выделенный Unix-пользователь, которому — за несколькими интересными исключениями — разрешён полный доступ ко всему в системе, и на которого не распространяются никакие ограничения прав.
Как и большинство других современных операционных систем, Android спроектирован с расчётом на то, что обыкновенному пользователю ни для чего не требуется использовать root-доступ. В отличие от более закрытых операционных систем, пользователи которых называют разрушение наложенных на них ограничений буквально «побегом из тюрьмы», в Android прямо «из коробки», без необходимости получать root-доступ и устанавливать специальные сторонние «твики», есть возможность:
Тем не менее, бывает, что root доступен пользователю:
Зачем это может быть нужно? Конечно, root-доступ полезен для отладки и исследования работы системы. Кроме того, обладая root-доступом, можно неограниченно настраивать систему, изменяя её темы, поведение и многие другие аспекты. Можно принудительно подменять код и ресурсы приложений — например, можно удалить из приложения рекламу или разблокировать его платную или скрытую функциональность. Можно устанавливать, изменять и удалять произвольные файлы, в том числе в разделе system (хотя это почти наверняка плохая идея).
С более философской точки зрения, root-доступ позволяет пользователю полностью контролировать своё устройство и свою систему — вместо того, чтобы устройство и разработчики ПО контролировали пользователя.
Проблемы root-доступа
With great power comes great responsibility.
С большими возможностями приходит и большая ответственность, и совсем не всегда эту ответственность можно доверить пользователю и приложениям. Другими словами, с root-доступом связано большое количество проблем в области безопасности и стабильности системы.
Напомню, что пользователь почти всегда взаимодействует с устройством не напрямую, а через приложения. А это значит, что и root-доступ он будет использовать в основном через приложения, которые, можно надеяться, будут добросовестно пользоваться root-доступом для хороших целей. Но если на устройстве доступен root, это, в принципе, означает, что приложения могут воспользоваться им и для нехороших целей — навредить системе, украсть ценные данные, заразить систему вирусом, установить кейлоггер и т.п.
Как я уже говорил во второй статье серии, в отличие от традиционной модели доверия программам в классическом Unix, Android рассчитан на то, что пользователь не может доверять сторонним приложениям — поэтому их и помещают в песочницу. Тем более нельзя доверять приложениям root-доступ, надеясь, что они будут использовать его только во благо. Фактически, root-доступ разрушает аккуратно выстроенную модель безопасности Android, снимая с приложений все ограничения и открывая им права на доступ ко всему в системе.
С другой стороны, и приложения не могут доверять устройству, на котором подключен root-доступ, поскольку на таком устройстве в его работу имеют возможность непредусмотренными способами вмешиваться пользователь и остальные приложения. Например, разработчики приложения, содержащего платную функциональность, естественно, не захотят, чтобы проверку совершения покупки можно было отключить. Многие приложения, работающие с особенно ценными данными — например, Google Pay (бывший Android Pay) — явно отказываются работать на устройствах с root-доступом, считая их недостаточно безопасными.
Аналогично, онлайн-игры вроде популярной Pokémon GO тоже отказываются работать на root-ованных устройствах, опасаясь, что игрок сможет с лёгкостью нарушить правила игры.
Google Play и root-доступ
Google разрешает производителям предустанавливать Google Play Store и Google Play Services только на устройства, где root-доступ отключён, тем самым делая Android более привлекательной платформой для разработчиков, которые, естественно, предпочитают вкладывать ресурсы в разработку под платформы, не позволяющие пользователям с лёгкостью вмешиваться в работу их приложений. А поскольку Play Store — наиболее известный и популярный (как среди разработчиков приложений, так и среди пользователей) магазин приложений для Android, большинство производителей предпочитают предустанавливать его на свои устройства. (Есть и исключения — например, Amazon использует собственный дистрибутив Android под названием Fire OS для своих устройств — Echo, Fire TV, Fire Phone, Kindle Fire Tablet — и не предустанавливает никаких приложений от Google). Именно поэтому root-доступ по умолчанию отключён на большинстве популярных Android-устройств.
Несмотря на ограничение для производителей, Google разрешает пользователям сборок, в которых разрешён root-доступ, самостоятельно устанавливать Google Play (обычно это делается путём установки готовых пакетов от проекта Open GApps); при этом Google требует, чтобы после установки пользователь вручную зарегистрировал устройство на специально предназначенной для этого странице регистрации.
Device manufacturers work with Google to certify that Android devices with Google apps installed are secure and will run apps correctly. To be certified, a device must pass Android compatibility tests. If you are unable to add a Google Account on your Android device, your Android device software might not have passed Android compatibility tests, or the device manufacturer has not submitted the results to Google to seek approval. As a result, your device is uncertified. This means that your device might not be secure.
If you are a User wanting to use custom ROMs on your device, please register your device by submitting your Google Services Framework Android ID below.
Ограничение доступа к root
В «обычном» Linux, как и в других Unix-системах, для получения root-доступа (с помощью команд sudo и su ) пользователю требуется ввести пароль (или свой, или пароль Unix-пользователя root, в зависимости от настройки системы и конкретной команды) или авторизоваться другим способом (например, с помощью отпечатка пальца). В дополнение к собственно авторизации это служит подтверждением того, что пользователь доверяет этой программе и согласен предоставить ей возможность воспользоваться root-доступом.
Стандартная версия команды su из Android Open Source Project не запрашивает подтверждения пользователя явно, но она доступна только Unix-пользователю shell (и самому root), что полностью отрезает приложениям возможность получать root-права. Многие сторонние реализации su позволяют любому приложению получать права суперпользователя, что, как я объяснил выше, очень плохо в плане безопасности.
Magisk
Хотя это действительно невероятно круто, нужно осознавать, что возможность использовать приложения вроде Google Pay на root-ованных устройствах несмотря на встроенные в них проверки — это не решение связанных с root-доступом проблем с безопасностью. Приложения, которым пользователь доверил root-доступ, по-прежнему могут решить вмешаться в работу системы и украсть деньги пользователя через Google Pay. Проблемы с безопасностью остаются, нам лишь удаётся закрыть на них глаза.
Magisk поддерживает systemless-ную установку готовых системных «твиков» в виде Magisk Modules, специальных пакетов для установки с использованием Magisk. В таком виде доступны, например, известный root-фреймворк Xposed и ViPER, набор продвинутых драйверов и настроек для воспроизведения звука.
SoC, драйвера и фрагментация
Системы на кристалле
Аппаратное обеспечение традиционных настольных и серверных компьютеров построено вокруг материнской платы, на которую устанавливаются такие важнейшие компоненты «харда», как центральный процессор и оперативная память, и к которой затем подключаются дополнительные платы — например, графическая и сетевая — содержащие остальные компоненты (соответственно, графический процессор и Wi-Fi адаптер).
В отличие от такой схемы, в большинстве Android-устройств используются так называемые системы на кристалле (system on a chip, SoC). Система на кристалле представляет собой набор компонентов компьютера — центральный процессор, блок оперативной памяти, порты ввода-вывода, графический процессор, LTE-, Bluetooth- и Wi-Fi-модемы и т.п. — полностью реализованных и интегрированных в рамках одного микрочипа. Такой подход позволяет не только уменьшить физический размер устройства, чтобы оно поместилось в кармане, и повысить его производительность за счёт большей локальности и лучшей интеграции между компонентами, но и значительно снизить его энергопотребление и тепловыделение, что особенно актуально для мобильных устройств, питающихся от встроенной батарейки и не имеющих систем активного охлаждения.
Но, конечно, системы на кристалле имеют и свои недостатки. Наиболее очевидный недостаток состоит в том, что такую систему нельзя «проапгрейдить», докупив, например, дополнительной оперативной памяти, как нельзя и заменить плохо работающий компонент. Это, в принципе, выгодно компаниям-производителям, поскольку побуждает людей покупать новые устройства, когда существующие морально устаревают или выходят из строя, вместо того, чтобы их точечно обновлять или ремонтировать.
О драйверах
Другой — гораздо более важный именно в контексте Android — недостаток SoC заключается в связанных с ними сложностях с драйверами. Как и в традиционных системах, основанных на отдельных платах, каждый компонент системы на кристалле — от камеры до LTE-модема — требует для работы использования специальных драйверов. Но в отличие от традиционных систем, эти драйвера обычно разрабатываются производителями систем на кристалле и специфичны для их конкретных моделей; кроме того, исходные коды таких драйверов обычно не раскрываются, да и бинарные сборки в свободный доступ производителями выкладываются совсем не всегда.
Вместо этого производитель SoC (например, Qualcomm) отдаёт готовую сборку драйверов производителям Android-устройств (например, Sony или LG), которые включают её в свою сборку Android, основанную на коде из Android Open Source Project. Так и получается, что сборка Android, предустановленная на устройстве производителем, содержит все нужные для этого устройства драйвера, а напрямую использовать сборку для одного устройства на другом невозможно.
В результате авторам сборок Android приходится прилагать отдельные усилия для поддержки каждого семейства моделей Android-устройств. Сами производители устройств совсем не всегда заинтересованы в том, чтобы выделять ресурсы на портирование своих сборок на новые версии Android. В то же время разработчикам сторонних дистрибутивов Android приходится извлекать драйвера из сборок, предустанавливаемых производителями, что связано с дополнительными сложностями и не всегда приводит к хорошему результату. У многих сторонних дистрибутивов хватает ресурсов только для поддержки наиболее популярных моделей устройств.
Фрагментация
Это приводит к проблеме, известной как фрагментация: экосистема Android состоит из большого количества различных сборок — как официальных сборок от производителей устройств, так и версий сторонних дистрибутивов. Многие из них к тому же основаны на старых версиях Android, поскольку для многих устройств обновления сборок от производителя выходят медленно или не выходят совсем.
Конечно, медленное обновление экосистемы означает, что не все пользователи получают небольшие обновления интерфейса и другие видимые пользователю улучшения, которые приносят новые версии Android. Но оно приносит и две гораздо более серьёзные проблемы.
Во-первых, страдает безопасность. Хотя современные системы используют продвинутые механизмы защиты, в них постоянно обнаруживаются новые уязвимости. Обычно эти уязвимости оперативно исправляются разработчиками, но это не помогает пользователям, если обновления системы, содержащие исправления, до них никогда не доходят.
Во-вторых, фрагментация отрицательно сказывается на разработчиках приложений под Android — страдает так называемый developer experience (DX, по аналогии с user experience/UX). В теории, несмотря на внутренние различия в драйверах и пользовательском интерфейсе разных версий и сборок Android, используемые разработчиками приложений API — Android Framework, OpenGL/Vulkan и другие — должны быть переносимы и работать одинаково. На практике это, конечно, не всегда так, и разработчикам приходится тестировать и обеспечивать работу своих приложений на множестве версий и сборок Android — на разных устройствах, разных версиях системы, сторонних дистрибутивах и так далее.
Don’t Stop Thinking About Tomorrow
Далеко не все производители Android-устройств не считают важным своевременно выпускать обновления для своих устройств. Например, Google выпускают обновления для своих линеек Nexus и Pixel одновременно с тем, как выходит новая версия Android. У многих других производителей портирование сборок Android на его новую версию занимает месяцы, но они, тем не менее, стараются выпускать ежемесячные обновления безопасности.
Кроме того, совсем не все устройства, где используется Android, построены на основе SoC. Android вполне можно установить и на обычный «десктопный» компьютер (подойдут, например, сборки от проектов Android-x86 и RemixOS). Специальная сборка Android встроена в ChromeOS, что позволяет Chromebook’ам запускать Android-приложения наряду с Linux-приложениями и веб-приложениями. Аналогичного подхода — запуска специальной сборки Android в контейнере — придерживается проект Anbox, позволяющий использовать Android-приложения на «обыкновенных» Linux-системах. (Напомню, что Android-приложения так легко переносятся на x86-архитектуры, не требуя перекомпиляции, благодаря использованию виртуальной машины Java, о чём я рассказывал во второй статье серии.)
И тем не менее, плохая переносимость сборок Android между разными устройствами и связанная с ней фрагментация экосистемы — это серьёзная проблема, затрудняющая развитие и продвижение Android как платформы.
Наиболее прямой способ бороться с фрагментацией — это всячески убеждать производителей устройств не забрасывать поддержку своих сборок Android. Как показывает практика, это работает, но работает недостаточно хорошо. Было бы гораздо лучше, если можно было бы разработать техническое решение, повышающее переносимость сборок Android и тем самым серьёзно облегчающее задачу авторов сборок и сторонних дистрибутивов.
И такое решение уже существует. В 2017 году Google анонсировали Project Treble — новую, ещё более модульную (по сравнению с уже существующим HAL, hardware abstraction layer) архитектуру взаимодействия драйверов (и остального софта, специфичного для конкретного устройства) с остальными частями системы. Treble позволяет устанавливать основную систему и драйвера, специфичные для устройства, на разные разделы файловой системы, и обновлять — или как угодно изменять — систему отдельно от установленных драйверов.
Treble в корне меняет ситуацию с медленным выпуском обновлений и плохой переносимостью сборок. Благодаря Treble устройства от семи разных компаний (Sony, Nokia, OnePlus, Oppo, Xiaomi, Essential и Vivo — а не только от самих Google) смогли участвовать в бета-программе Android Pie. Treble позволил Essential выпустить обновление до Android Pie для своего Essential Phone прямо в день выхода Android Pie. Одну и ту же сборку Android — один и тот же бинарный файл без перекомпиляции или каких-либо изменений — теперь можно запускать на любом устройстве, поддерживающем Treble, несмотря на то, что они могут быть основаны на совершенно разных SoC.
Влияние Treble действительно сложно переоценить. Java принесла возможность «write once, run everywhere» для высокоуровневого кода — в том числе и возможность запускать Android-приложения на компьютерах с практически любой архитектурой процессора. Treble — аналогичный прорыв, позволяющий использовать однажды написанную и скомпилированную сборку Android на устройствах с совершенно разными SoC. Теперь дело за производителями, которым нужно конвертировать свои драйвера в формат, совместимый с Treble. Можно надеяться, что через несколько лет проблемы с обновлениями Android-устройств исчезнут окончательно.
В следующей статье я планирую рассказать о низкоуровневом userspace Android: о процессе init, о Zygote, Binder, сервисах и props.