В этом посте я буду собирать различные факты, относящиеся к AndroidManifest.xml, приводящие меня, как разработчика, в замешательство. Таких вещей довольно много и не все из них заслуживают отдельной статьи. Если вам попадется какая-нибудь странность, не упомянутая здесь, либо вы знаете информацию, объясняющую, что на самом деле все правильно и я просто чего-то не понял — пишите об этом в комментариях.

Uses-permissions и видимость в Google Play

Недавно я опозорился на собеседовании. Речь шла о понятиях uses-permission и uses-feature. Я, не сомневаясь в своем знании этой темы, отвечал уверенно и твердо. И вот прозвучал вопрос: «Если в манифесте объявить uses-permission для камеры, будет ли приложение в маркете видимо для девайсов, не имеющих камеру?» К сожалению, несмотря на несколько лет работы с андроидом, мне ни разу не доводилось собственноручно выкладывать приложения в Google Play. То проект был для внутренних нужд, то распространялся другими путями, то заказчик предпочитал заняться деплоем самостоятельно. Поэтому, при ответе на этот вопрос я решил воспользоваться логикой, тем более что здесь все кажется очевидным — для управления видимостью используется элемент uses-feature, а uses-permission нужен лишь для того, чтобы получить разрешение на использование какого-либо API. Ведь если мы используем камеру в приложении, это вовсе не означает, что камера жизненно необходима. К сожалению, в случае с андроидом логика часто оказывается беспомощной. И мой собеседующий с удовлетворенной улыбкой сообщил мне, что я неправ — пользователи с девайсами без камеры не увидят приложение в маркете, если я просто добавлю это разрешение. А для того, чтобы увидели, нужно прописать uses-feature с атрибутом required = false, т.е.:

Это показалось мне настолько неправдоподобным, что я пару минут спорил, утверждая, что это невозможно. Каким образом добавление android.permission.CAMERA может автоматически делать обязательным android.hardware.camera? Ну, теоретически реализацию подобной связи представить можно, но кажется маловероятным, что кто-то в здравом уме стал бы ее добавлять. Неужели не очевидно, что в большинстве случаев наличие работы с камерой в приложении не подразумевает того, что приложением нельзя пользоваться без камеры?

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

Круглые иконки

Читая о нововведениях Android 7.1, я наткнулся на упоминание круглых иконок. Отныне в манифесте для таких элементов, как application и activity, в дополнение к атрибуту icon можно указать roundIcon. Это ссылка на drawable, представляющий из себя иконку приложения на фоне одноцветного круга с тенью. Белый круг с тенью предлагается нарисовать самостоятельно (на самом деле можно воспользоваться утилитой Image Asset Studio). Нововведение объясняется тем, что одни девайсы будут использовать icon, а другие, такие как Google Pixel — roundIcon.

Первое, что приходит в голову — зачем привязываться к круглой форме? Гугл, давай начистоту — ты не можешь гарантировать, что Material Design будет существовать вечно, и уж тем более в таком же самом виде как сейчас. Сегодня в моде иконки на круглом фоне, а завтра — на фоне треугольника. И roundIcon останется в манифесте legacy-артефактом, который с годами пометят как deprecated, а в итоге удалят.

Как бы это реализовал я: во-первых, никак, это просто не нужно. Если все же очень нужно, то я предпочел бы, чтобы система сама отрисовывала фон иконки. Разработчику достаточно было бы предоставить предпочитаемый цвет этого фона, а также отрисовываемый на нем ресурс. Не нужно привязываться к слову «круглый/round» — пусть девайс сам решит, как отрисовать иконку — на круге, квадрате, шестерне, Библии в руках Иисуса и т.д.