Среднестатистического пользователя Android, вероятно, уже давно перестала волновать «проблема фрагментации» Android. Но эта проблема все еще не дает покоя разработчикам.
Фрагментация была спорным вопросом в Android буквально с момента анонса мобильной операционной системы.
Помимо того, что это дубинка для троллей, которую они могут использовать в онлайн-войнах, разнообразие, возникающее в результате фрагментации, теперь в значительной степени рассматривается как чистый позитив для потребителей устройств Android. В конце концов, нам дана такая большая свобода в выборе типа устройства с тем программным обеспечением, которое мы хотим, что обычному потребителю трудно заботиться о фрагментации. Визуализация невероятного разнообразия устройств Android создает прекрасную мозаику разнообразного представления Android.
Но фрагментация аппаратного и программного обеспечения не делает разработчика программного обеспечения счастливым. На самом деле, совсем наоборот. Разработка приложения для такого количества различных конфигураций оборудования и программного обеспечения может оказаться серьезной проблемой при отладке. OEM-производители могут вносить существенные или незначительные изменения, которые необходимо учитывать при разработке приложения, но на самом деле у отдельного разработчика нет простого способа гарантировать, что его приложение будет работать универсально. Хотя средний потребитель уже давно забыл о дебатах о фрагментации, эта проблема все еще преследует Android. разработчиков приложений, и, похоже, с этим ничего не поделаешь, кроме как смириться с ошибками и разобраться с ними по мере того, как они появляться.
Жалкое состояние фрагментации
В частности, один OEM-производитель получает большую часть ненависти за головную боль, которую они причиняют при разработке приложения — Samsung. Разработчики уже много лет разглагольствуют о Samsung, а некоторые даже пишут такие резкие статьи, как «В Android-аде для Samsung есть особое место", который описывает особенно неприятную ошибку, возникающую из-за Устройства Samsung и библиотека поддержки appcompat. Я хотел бы обратить внимание, в частности, на один абзац из напыщенной речи г-на Амбри, который прекрасно описывает, почему разработчики все еще заботятся о фрагментации:
Если вы разработчик Android, ваша ненависть к устройствам Samsung, вероятно, безгранична. Больше, чем обычный пользователь, для которого Samsung является синонимом глупый Тачвиз и чрезмерное раздутое ПО, вы презираете Samsung, потому что у вас нет выбора. Из-за Samsung огромная доля рынка, вы просто не можете отказаться от поддержки устройств Samsung. И это то, что ранит больше всего; в том, что этот выбор у тебя отнят!
Это тоже не пустословие из былых лет существования Android — этот пост был опубликован в середине декабря прошлого года. Я буду откровенен и заявлю, что не уверен, решена ли эта проблема официально, однако г-н. Амбри предоставил исправление в своем сообщении для всех, кто наткнулся на его напыщенную речь через поиск в Google. ошибка. Все, что вам нужно сделать, это использовать ПроГард с помощью следующей единственной строки кода:
# Samsung ruining all nice things-keep class !android.support.v7.view.menu.**, !android.support.design.internal.NavigationMenu, !android.support.design.internal.NavigationMenuPresenter, !android.support.design.internal.NavigationSubMenu, android.support.** {*;}Это не так уж и плохо, не так ли? Проблема, однако, в том, что это исправление было удалено из Stack Overflow. Не поймите меня неправильно, Stack Overflow — отличный веб-сайт. Но на самом деле это не идеальный источник для поиска исправлений для ваших приложений. Поиск чего-либо в Stack Overflow часто требует глубокого изучения ссылок после множества поисков в Google методом проб и ошибок. Иногда вы даже обнаружите, что другой пользователь упоминает ту же ошибку, что и у вас, но исправления не видно. Или, что еще более неприятно, когда вы находите тему, в которой оригинальный автор утверждал, что нашли исправление, но они уже давно покинули свою тему, не проинструктировав других, как исправить проблема.
Пример тонкой проблемы фрагментации
Я сам не разработчик, но после многих лет работы с Tasker я достаточно знаком с возможностями Android, поэтому начал псевдопрограммировать собственные решения проблем, с которыми столкнулся. А когда я не могу что-то понять, я гуглю это, как и все остальные. Пока я писал свою предыдущую статью о покопайтесь в приложении «Настройки» вашего телефона на предмет скрытых действий, я столкнулся с довольно странной ошибкой, которую не мог объяснить. Ошибка, уникальная для устройств Huawei.
Всякий раз, когда я пытался запустить определенные действия (например, меню «Тестирование», содержащее статистику использования приложения) в приложении «Настройки», я всегда получал ошибку разрешения. В частности, у приложения, которое я использовал для начала действия, не было разрешения. huawei.android.разрешение. HW_SIGNATURE_OR_SYSTEM. Ни одно другое протестированное мной устройство не требовало каких-либо уникальных разрешений для запуска этих действий в настройках, только телефоны под управлением версии Android (EMUI) от Huawei. Анализ com.android.settings выявило, что некоторые действия в приложении «Настройки» действительно находились под уровнем защиты, требующим либо подпись или разрешение системы.
К сожалению для меня, это означает, что только приложения, установленные в /system, или приложения, подписанные тем же подпись, поскольку приложение «Настройки» сможет открывать эти действия тем же способом, который я использовал. попытка. Когда я искал в Google ответ на эту ошибку, я (как вы уже догадались) наткнулся на Поток переполнения стека. Разработчик, опубликовавший свою проблему, столкнулся с той же проблемой, что и я (хотя на самом деле он находился в процессе разработки приложения). Его проблема возникла, когда он попытался запустить следующий код:
<span >Intentspan><span > mainIntent span><span >=span><span >newspan><span >Intentspan><span >(span><span >Intentspan><span >.span><span >ACTION_MAINspan><span >,span><span >nullspan><span >);span><span >mainIntentspan><span >.span><span >addCategoryspan><span >(span><span >Intentspan><span >.span><span >CATEGORY_LAUNCHERspan><span >);span><span >Intentspan><span > pickIntent span><span >=span><span >newspan><span >Intentspan><span >(span><span >Intentspan><span >.span><span >ACTION_PICK_ACTIVITYspan><span >);span><span >pickIntentspan><span >.span><span >putExtraspan><span >(span><span >Intentspan><span >.span><span >EXTRA_TITLEspan><span >,span><span >"Pick App to Play in"span><span >);span><span >pickIntentspan><span >.span><span >putExtraspan><span >(span><span >Intentspan><span >.span><span >EXTRA_INTENTspan><span >,span><span > mainIntentspan><span >);span><span >thisspan><span >.span><span >startActivityForResultspan><span >(span><span >pickIntentspan><span >,span><span > REQUEST_PICK_APPLICATIONspan><span >);span>Судя по строкам в намерении и на веб-странице разработчика, он, вероятно, пытался позволить пользователю выбрать стороннее приложение для воспроизведения медиафайлов. Исправление, предоставленное опытным разработчиком. CommonsWare, было довольно просто: используйте Намерение. СоздатьВыборщик вместо ACTION_PICK_ACTIVITY. Однако, почему нужно ли нам внедрять это исправление? Почему требует ли Huawei это разрешение в первую очередь? Почему нам нужно было найти ответ на StackOverflow, используя очень специфический поиск в Google?
Парадокс выбора
Чтобы найти ответ, CommonsWare подала отчет об ошибке в системе отслеживания ошибок Android с просьбой к Google разобраться в проблеме. В частности, разработчик потребовал, чтобы Google запретил недокументированным требованиям разрешения ограничивать доступ сторонних приложений к ACTION_PICK_ACTIVITY. Написав эти требования в КТС, Huawei будет вынуждена соблюдать эти изменения.
Честно говоря, сама по себе эта ошибка не имеет большого значения. Хотя ни одно другое приложение, которое я пробовал (например, Tasker), не смогло обойти это разрешение. требование и запускать определенные действия в приложении «Настройки», меня это не особо разочаровало. исход. Но когда я вспомнил напыщенную речь г-на Амбри, я понял, что с такими небольшими изменениями, должно быть, очень неприятно иметь дело, особенно потому что какими бы крошечными они ни были, они, несомненно,сложить, иногда достаточно, чтобы вызвать головную боль. Одно крошечное изменение в приложении «Настройки» может привести к незаслуженному негативному отзыву в адрес разработчика. Одно крошечное изменение, которое довольно плохо документировано и потребовало от меня поискать в Интернете ветку о переполнении стека. Сколько еще мелких ошибок есть на других устройствах?
Возросшая конкуренция в мобильном пространстве оказалась полезной для потребителей, но после того, как они увидели, как эти тонкие изменения в столь многих различных линейках продуктов могут влиять на разработчиков, я стал ценить точку зрения разработчиков на фрагментация. Проблема не в том, что сам выбор является проблемой, а в том, что сообщество не делает достаточно для систематизации этих проблем. Как предположил г-н Амбри в своей статье, возможно, разработчикам Android нужна собственная версия caniuse.com или sdkcritic.com собрать все малоизвестные ошибки в одну базу данных. Единственная альтернатива — заставить OEM-производителей либо должным образом документировать эти изменения, либо вообще прекратить их вносить. Удачи с этим.
Кредиты на изображения: OpenSignal