26 февраля 2014

Беседка №7: о невозможности форка Android

Илья Субботин

Логическое продолжение темы Беседки прошлой недели, представляющее собой развернутый анализ невозможности получения адекватного продукта путем форка ОС от Google. Частично затрагивается проект Nokia Х, рассматривается целесообразность перехода Microsoft на Android, в общем, много интересного. Приятного чтения!

Недавно, как происходит время от времени, было высказано предположение об отказе Microsoft от Windows в пользу форка Android. Это не первый и не последний такой случай. Идея плохая: Google постарался сделать Android функционально невозможным для форка и лишенным способа одновременно создать ответвление платформы и воспользоваться преимуществом её сильных сторон: развитого сообщества разработчиков и обилия приложений.

Аргумент за форк компанией Microsoft ОС от Google заключается в следующем: Windows Phone, в отличии от Android, не имеет ни хороших показателей продаж, ни большого числа заинтересованных разработчиков. Осуществляя форк Android, Microsoft сможет заложить уникальный потенциал – общую интеграцию с такими сервисами, как Exchange, Active Directory и System Center или InTune; полную поддержку Office; «вылизанную» систему взаимодействия с пользователем – и обеспечить привязку платформы к своим «облачным» сервисам (Bing, Bing Maps, Azure), нежели аналогичным от Google. Но, в то же время, платформа имела бы доступ ко всем популярным среди пользователей Android-приложениям.

Результатом такого перехода стала бы платформа, в чем-то более привлекательная для пользователей благодаря бренду Android и всем его приложениям, более интересная разработчикам благодаря Android API, более дешевая для Microsoft для разработки, т.к. разработка основ ОС – дело Google. Однако, всё эти идеи обречены на провал потому, что в таком формате не получится использовать Android. Платформа не предназначена для этого. На деле, с каждым новой версией Android Google делает «форкнутую» ОС всё менее жизнеспособной и целесообразной.

Не совсем открытый исходный код

Не вдаваясь в тонкости, Google создает два больших куска кода. Первый — это кодовая база Android Open Source Platform (AOSP). Она содержит базовые основы ОС для смартфона: включает версию ядра Linux для Android, Dalvik и элементы основного пользовательского интерфейса (настройки, панель уведомлений, экран блокировки). Эта часть подлежит лицензированию GPL и Apache. Google периодически обновляет код для этих «открытых» элементов, хоть и подвергается критике за ведение разработок по большей части за закрытыми дверями.

Второй кусок кода — Google Mobile Services (GMS, иногда он называется Google Services, иногда – Google Play или Google Play Apps, в коде присутствует обозначение GMS, по всей видимости, это общепринятое название). Он, в свою очередь, делится на две большие части. GMS предоставляет множество API и системных служб: API для Google Maps, местоположения и покупок внутри приложений; интеграцию Google+, удаленный сброс устройства, поиск угроз и многое другое. Также, сюда входит группа приложений из каталога Play: Google Поиск, Gmail, Chrome, Карты и т.д.

GMS имеют несколько важных функций. GMS не является продуктом с открытым исходным кодом. Любой может взять AOSP и «впихнуть» в телефон. С GMS всё не так. Для получения доступа к GMS устройство должно отвечать конкретным техническим параметрам (производительность, разрешение дисплея, etc.) и должно пройти проверку. Хоть Google и говорит, что набор GMS сам по себе бесплатен, но процесс проверки таковым не является, и по некоторым данным обходится в 75 центов за устройство.

GMS также неделимы: если телефон проходит GMS-лицензирование и может поставляться с этим набором, то в нем будет всё: как сервисы Play, так и различные приложения от Google, которые используют эти сервисы.

Android — открытая платформа, не считая всех хороших элементов

Разрыв между AOSP и GMS — непостоянный. Google плавно начал переводить всё большую функциональность в GMS. Например, в последнем Nexus 5, базовый телефонный пользовательский интерфейс – используемый для запуска приложений и отображения иконок – был включен в состав приложения Google Search. По аналогичной схеме происходит и с API. AOSP включает в себя API касаемо местоположения, но в GMS уже включен его аналог, новый, улучшенный и дополненный функциями. Google поощряет использование разработчиками GMS API, а уже упомянутый API AOSP по большей части относится к Android 1.0 и не подвергался значимым изменениям со времен Android 1.5. Как результат, большинство сторонних приложений являются не просто Android-приложениями, а GMS-приложениями, которые не будут работать без проприетарного и закрытого программного обеспечения Google.

4 пути к Android

Существуют 4 способа, которые могут быть использованы производителями «железа» для использования Android в своих телефонах.

Первый путь – это способ использования ОС, которым, как на самом деле хотят в Google, должны пользоваться компании: AOSP+GMS. Прохождение сертификации, включение в аппарат всех сервисов и приложений от Google. Таким образом поступают, например, компании, Samsung, HTC и LG. Всё же, данный путь несколько облегчает кастомизацию для OEM-производителей. Например, они могут включать [в программное обеспечение] свои приложения наряду с «гугловскими». Выходит, что в Google не особо рады такому положению вещей – недавно прошла информация, что компания заключила соглашение с Samsung, направленное на уменьшение кастомизации пользовательского интерфейса и исключения из числа приоритетных или вовсе удаления приложений Samsung, представляющих прямую конкуренцию эквивалентным решениям от Google.

Выбор данного пути помогает достичь лучшей совместимости со сторонними приложениями с помощью API, доступных и для AOSP, и для GMS. Здесь также играет и постоянство: несмотря на различные внесенные изменения, такое положение вещей означает доступность приложений Google и их одинаковую работу на любом AOSP+GMS-устройстве. Такой путь предоставляет большую часть контроля Google, и его уровень будет только расти. Каждый релиз увеличивает уровень интеграции с сервисами Google, который, как уже было отмечено, переносит всё больше функциональности в GMS, оставляя от AOSP лишь «ободранный остов».

Другой подход подразумевает полное игнорирование GMS. Поставка телефона с AOSP и возможно каким-то дополнительным софтом поверх него, что создаст некоторые трудности для пользователей, зато дело сделано. В самом дешевом сегменте рынка есть компании, которые так и поступают; это характерно, прежде всего, для Китая. OEM-производители по желанию могут добавлять собственные магазины приложений и другие сервисы с целью заполнить пустые ниши, которые могли заполняться продуктами GMS, но такие устройства всегда будут проигрывать устройствам с набором сервисов от Google, они не будут совместимы со сторонними приложениями, использующими API GMS. Такие приложения составляют немаленькую категорию, ведь такие функции, как покупка внутри приложений заложены именно в GMS.

Третий вариант охватывает оба вышеуказанных пути: поставка устройства с AOSP и эквивалентом GMS, который обуславливает новое применение для тех же API; включение схожих решений для таких сервисов, как определение местоположения и карты, но углубление в сервисы Microsoft, нежели Google. Ни одна компания по сути не воспользовалась данным способом. Ближе всего была Amazon, которая предоставляет стоящие альтернативы для некоторых API Google (в частности карт), но которая еще не может тягаться с развитием GMS.

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

Здесь присутствуют и несколько неуклюжие аспекты GMS API: в набор включены такие возможности, как «поделиться при помощи Google+», соцсети, реальных альтернатив которой не имеется почти ни у кого. Еще один пример: есть API, управляющий многопользовательским пошаговым игровым процессом. Компания может применить этот API и иметь собственную структуру серверов для управления игровыми сессиями, но очевидно, эти сессии будут полностью отделены от игровых сессий Google, фрагментируя базу игроков таким образом, что разработчикам игр весьма вероятно это не понравится.

И дополнительным бонусом может стать окончательное разрешение долгой судебной тяжбы между Google и Oracle на предмет возможности API выступать как объект, охраняемый авторским правом, в случае такого разрешения спора вышеуказанное повсеместное внедрение GMS сможет стать основанием для иска. Если Google решит, то сможет отключить сервисы посредством обращения в суд.

К этим трём опциям можно добавить четвертую: использовать AOSP для обеспечения некоторых основных сервисов – поддержки «железа», телефонии и т.д. – но затем построить абсолютно новую платформу и API под нее. Под данную категорию подпадают API от Amazon, некоторые из которых работают в тех же областях, что и GMS API, но в абсолютно в другом, несовместимом формате. И всё-таки непонятно, пошел ли кто-либо из производителей по этому пути до конца, хоть могут и возникнуть споры, что Ubuntu для Android схож с ним, по крайней мере, по духу.

Совместимость или контроль, одно из двух

Первая опция – AOSP+GMS – единственная, обеспечивающая полный пользовательский опыт Android. Единственный путь, гарантирующий отличное применение навыков разработчиков, единственный обеспечивающий разнообразие и широкий охват программного обеспечения для Android. Всё же, это не очень хороший вариант для Microsoft, принимая во внимание тот факт, что таким образом весь контроль над платформой будет у Google, и судя по рекламной кампании, этот контроль будет усиливаться с каждой новой версии.

Второй путь – AOSP с некоторыми кастомными дополнениями – имеет положительную сторону, предоставляя Microsoft возможность интеграции своих сервисов. Будет присутствовать поддержка Android-софта, однако, неясно, какой его части. В список поддерживаемых точно не попадут популярные приложения с внутриигровыми покупками, например, «Plants vs. Zombies 2» или последние «Angry Birds». Если бы кто-то решился создать «feature-phone», то этот путь мог бы подойти. Когда телефон создается только для того, чтобы работать со встроенными приложениями (камера, браузер, почтовый клиент), факт несовместимости со многими Android-приложениями теряет свою значимость. Слухи об Android-телефоне от Nokia подразумевают именно такой подход: AOSP на борту, но с сервисами Nokia, а не Google.

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

Как бы то ни было, важно понимать, каким неполноценным будет такое устройство. В GMS были введены очень важные функции, включающие в себя обмен сообщениями и браузер Chrome. Эквиваленты из AOSP полны багов, лишены дополнительных функций и, по некоторой информации, едва поддерживаются. Если компания хочет использовать AOSP без GMS, то ей предстоит выполнить большую работу для обеспечения высококачественного пользовательского опыта. Элементы с открытым кодом просто не настолько хороши. Опыт Amazon Kindle также показывает, каким непростым делом может стать похожая на Android, но основанная на AOSP платформа. На Kindle отсутствуют последние и лучшие Android-игры, т.к. разработчики не озаботились созданием не-GMS-версий своих игр, хоть платформа Kindle и очень похожа на версию Google. Другими словами, проблему с приложениями, с которой столкнулась Windows Phone, не решить при помощи AOSP. Единственный способ решить проблемы с приложениями – быть платформой, основанной на GMS, а не на AOSP.

Третий способ – AOSP с «доморощенной» заменой GMS — может решить проблемы, но он также увеличит затраты и усилия на разработку. Обеспечение эквивалентов каждого из компонентов GMS должно, по крайней мере, предоставлять пользователям адекватный опыт. Этот способ также восстановит совместимость программного обеспечения, которую теряет AOSP без GMS. Однако, это большое упущение. Для Microsoft, усилия для создания функционального эквивалента для GMS поверх AOSP будут сравнимы с созданием оболочки и API для Windows Phone поверх Windows. Фактически, это вполне вероятно будет чем-то большим. Например, у Microsoft уже есть движок браузера, который работает на Windows. Работающего на AOSP не имеется. Более того, такой вариант все же косвенно предоставляет Google контроль над платформой. Различные аспекты использования Android определяются базовыми API, например, обмен между приложениями осуществляется в стиле, характерном для Android. Любая платформа, использующая Android таким образом, будет иметь лишь ограниченную возможность «увести» развитие ОС в сторону от задуманного Google пути.

Четвертый способ – использование AOSP с абсолютно новым набором программного обеспечения – дает свободу и гибкость действий, но до какого предела? Ядро не играет здесь роли. У Microsoft есть собственное ядро для смартфонов. Его уже использует Windows Phone 8. И, удивительно для Microsoft, отказ от Windows Phone не значит, что компания должна останавливать развитие ядра. Он уже был разработан под Windows. Ядро не создаст проблем.

«Fork off»

(непередаваемая игра слов)

Если бы Android был такой же открытой платформой, как Firefox OS или Ubuntu для смартфонов, то предположение о возможности форка имело бы больше смысла. Разрыв между AOSP и GMS не существовал бы. Всё бы работало в AOSP, поэтому была бы применима фрагментарная замена внутренних сервисов без необходимости переписывать большие куски кода и значительных проблем с совместимостью. Но это не так. Платформа не только не настолько открыта, но Google ко всему прочему активно работает над тем, чтобы сделать её функционально менее открытой с каждым релизом. В результате человеку или компании, решившей сделать форк, придется выбирать: отдать ли контроль Google и получить все преимущества платформы или же забрать этот контроль и практически не получить их.

Android не создан для форка. Посредством GMS Google намеренно создал барьер для этого. Предположения о том, что Microsoft может забраковать свою ОС в пользу такого форка, являются следствием непонимания принципов, в соответствии с которыми Google создал платформу Android.

Оригинальная статья, автор Питер Брайт

Elir: довольно объемная статья, раскладывающая по полочкам преимущества и недостатки форка, а также показывающая возможное отсутствие перспектив в дальнейшем. На ваш взгляд, по сравнению с мнением, высказанным в предыдущей Беседке, какое из них более применимо?