Поддержка app в наушниках — что это?
При приобретении наушников следует предварительно обладать знаниями по некоторым характеристикам изделия. Таким образом, в статье рассмотрим один из параметров передачи данных и узнаем основные особенности.
Поддержка app в наушниках — что это такое?
Конечно, для начала необходимо понимать, что представленная технология представляет собой вариант для получения действительно качественного звука с помощью bluetooth. Следовательно, для такого достижения эффекта звучание воспроизводимой записи сжимается непосредственно в дорожке. С её помощью, при определённой чистоте и глубине выборке, скорость достигается значительных показателей.
ВНИМАНИЕ. Существует миф, что качество достаточно ухудшается. Соответственно, это не совсем так, поскольку файл передаётся не только корректно, но и с высоким битрейтом. Тем более что за счёт современных производителей, с каждым годом то или иное устройство постоянно модернизируется.
Точно можно сказать, что звучание из того или иного агрегата будет по качеству намного лучше, нежели он воспроизводился с отсутствием кодека. На сегодняшнее время, за счёт своей эффективности и некоторой значимости, почти в каждом сооружении обладает данная технология, которая отправляет аудиосигнал непосредственно через bluetooth-канал.
Особенности
Для того чтобы максимально точно определить данную технологию, желательно рассмотреть следующие аспекты:
Таким образом, в каждой особенности возможно найти как достоинства, так и недостатки. При выборе стоит опираться на цель покупки. Кроме этого, стоит обращать внимание на обновлённые версии, которые технически, скорее всего, намного лучше своих предшественников.
App version что это
В статье приведен перевод статей [1, 2], посвященных управлению версиями приложения Android, и работе приложения на разных версиях операционной системы Android. Все непонятные термины и сокращения ищите в Словарике [3].
Управление версией приложения является критически важным аспектом для обновления приложения и для стратегии его поддержки в будущем. Это важно потому что:
Система Android не использует информацию об версии приложения для принудительного ограничения на апгрейд, довнгрейд, или на ограничение совместимости приложений сторонних производителей. Вместо этого Вы (как разработчик) отвечаете за ограничения, связанные с версиями приложения, или за информирование об этом пользователей. Однако система Android обеспечивает совместимость приложения с системой в соответствии с атрибутом minSdkVersion, который указан в манифесте. Этот атрибут позволяет приложению указать минимальный уровень системного API, с которым совместимо приложение. Дополнительную информацию см. ниже android:minSdkVersion в разделе «Как указать требования приложения к уровню (версии) API Android».
[Установка версии приложения (Application Version)]
Чтобы задать информацию о версии для Вашего приложения, нужно установить атрибуты в файле манифеста приложения (AndroidManifest.xml, секция manifest). Доступно 2 атрибута, для которых обязательно нужно назначить значения:
Обычно Вы должны сделать первый релиз приложения с versionCode установленным в 1, и затем монотонно увеличивать это значение с каждым новым релизом, независимо от статуса, который имеет релиз: major или minor. Это не означает, что значение атрибута android:versionCode должно быть строго подобно версии релиза, которую видит пользователь (см. далее атрибут android:versionName). Приложения и сервисы публикации приложений не должны отображать значение атрибута android:versionCode для пользователей.
Как и атрибут android:versionCode, система Android не использует android:versionName для внутреннего использования, кроме того как отобразить это значение для пользователей. Сервисы публикации приложений могут также прочитать значение android:versionName для того, чтобы отобразить её для пользователей.
Оба этих элемента нужно задать в секции файла манифеста приложения. Пример:
Рабочее окружение Android предоставляет API, позволяющее приложениям опросить систему для получения информации версии приложения. Чтобы получить информацию версии, приложения используют метод getPackageInfo(java.lang.String, int) объекта PackageManager.
[Как указать требования приложения к уровню (версии) API Android]
Если Ваше приложение требует определенную минимальную версию платформы Android, где приложение должно работать, или если приложение разработано для поддержки определенного диапазона версий платформ Android, то Вы можете указать эти требования к версиям в виде идентификаторов API Level в файле манифеста приложения. Если сделать так, то это обеспечит то, что Ваше приложение может быть установлено только на устройствах, на которых работает совместимая версия системы Android.
Чтобы указать требования к API Level, добавьте тег в файл манифеста приложения, и укажите в нем один или несколько этих атрибутов:
При подготовке к установке приложения система проверяет эти атрибуты и сравнивает их с версией системы. Если значение android:minSdkVersion больше версии системы, то установка приложения будет прервана. Точно также система установить Ваше приложение только в том случае, если android:maxSdkVersion совместим с версией платформы.
Если Вы не укажете эти атрибуты в манифесте, то система предположит, что Ваше приложение совместимо со всеми версиями платформы, и также нет ограничения на максимальный API Level.
[Подробнее о секции манифеста ]
Секция uses-sdk появилась начиная с API Level 1 (т. е. сразу, начиная с самых старых версий Android). Синтаксис секции следующий:
Секция uses-sdk позволяет Вам выражать совместимость приложения Android с одной или большим количеством версий платформ (операционных систем) Android. Эта совместимость определяется посредством чисел API Level, которая указывается в атрибутах секции minSdkVersion, targetSdkVersion, maxSdkVersion. Версия платформы может (которая соответствует определенному числу API Level) может различаться на разных устройствах Android. Указанные API Level, представленные приложением в этой секции, сравниваются с API Level системы, на которой работает (или устанавливается) приложение, и на основе этого сравнения принимаются определенные решения по инсталляции программы или её работе.
Несмотря на имя секции uses-sdk, эта секция на самом деле используется для определения API Level, но не номер версии SDK платформы Android. API Level всегда задается одиночным целым числом. Вы не можете получить из связанной с ним текстовой версии Android, кроме как получить такое соответствие из таблицы API Level (см. [4]). К примеру, API level 16 относится к версиям Android 4.1, Android 4.1.1, Android 4.1.2. Теперь рассмотрим назначение атрибутов minSdkVersion, targetSdkVersion, maxSdkVersion.
android:minSdkVersion число, обозначающее минимальный API Level, который требуется для установки, запуска и работы приложения. Система Android не позволит пользователю установить приложение, если API Level системы меньше значения, указанного в этом атрибуте. Вы всегда должны указывать этот атрибут в секции uses-sdk файла AndroidManifest.xml.
Предостережение: если Вы не укажете этот атрибут, то система предположит его значение по умолчанию «1», что означает совместимость Вашего приложения со всеми без исключения версиями операционной системы Android. Если Ваше приложение несовместимо со всеми версиями (например, оно использует API, представленное впервые на API Level 3), и Вы не укажете правильно minSdkVersion, то при установке на систему с уровнем API Level меньше 3 приложение будет завершаться с ошибкой при попытке доступа к недоступному API. По этой причине обязательно объявляйте подходящий API Level в атрибуте minSdkVersion.
android:targetSdkVersion этот атрибут представлен начиная с API Level 4. Это целое число, обозначающее API Level, для которого приложение предназначено (target, что означает цель). Если этот атрибут не установлен, то его значение по умолчанию равно minSdkVersion.
Этот атрибут информирует систему, что Вы тестировали приложение с этим API Level, и система не должна позволять любое поведение совместимости (compatibility behaviors, т. е. эмуляцию вызовов API, обеспечивающих специальную дополнительную программную обработку некоторых вызовов API), чтобы поддержать прямую совместимость приложения с целевой версией системы. Приложение все еще может работать на более старых версиях (до версий, не меньших minSdkVersion).
Поскольку Android развивается с каждой новой версией, то некоторые поведения и даже внешний вид приложения может измениться. Однако, если API level платформы выше, чем версия, указанная в targetSdkVersion приложения, система может включить обработки совместимости (compatibility behaviors), чтобы обеспечить работоспособность Вашего приложения так, как Вы этого ожидали. Вы можете запретить такие обработки совместимости, если укажете targetSdkVersion равным API level платформы Android, на которой приложение работает. Например, установка этого значения в «11» или более высокое значение позволит системе установить новую тему оформления по умолчанию (Holo) для Вашего приложения при работе на Android 3.0 или более новой, и также запретит режим совместимости экрана, когда программа будет работать на больших экранах (потому что поддержка API level 11 неявно подразумевает поддержку больших экранов).
Имеется много разновидностей обеспечения совместимости (compatibility behaviors), которые система может разрешить, базируясь на значении этого атрибута. Некоторые из этих обработок (поведений, behaviors) описаны в соответствующей документации версии платформы, см. Build.VERSION_CODES.
Чтобы обеспечить соответствие Вашего приложения каждому новому релизу Android, Вы должны увеличивать значение этого атрибута, чтобы оно соответствовало последнему API level, и затем необходимо полностью протестировать поведение приложения на этой новой версии платформы.
android:maxSdkVersion этот атрибут представлен начиная с API Level 4. Это целое число, обозначающее максимальный API Level, на котором приложение может работать.
На версиях Android 1.5, 1.6, 2.0 и 2.0.1 система проверяет значение этого атрибута, когда инсталлируется приложение, и когда приложение проверяется на совместимость после обновления системы. В любом случае, если атрибут приложения maxSdkVersion меньше API Level системы, то установка приложения будет запрещена. При проверке приложения на совместимость после обновления системы такой случай соответствует полному удалению приложения с устройства. Для иллюстрации того, как этот атрибут может повлиять на приложение после обновления системы, рассмотрим пример.
Приложение декларировало maxSdkVersion=»5″ в своем манифесте, и было опубликовано на Google Play. Пользователь устройства Android 1.6 (API Level 4) загрузил и установил это приложение. После нескольких недель пользователь принял сообщение от системы over-the-air с предложением обновить систему до уровня Android 2.0 (API Level 5). После установки этого обновления система проверила атрибут приложения maxSdkVersion, и разрешила дальнейшее использование этого приложения. Приложение после этого работало нормально. Однако через некоторое время устройство приняло другое обновление системы Android 2.0.1 (API Level 6). После обновления система не разрешает работу приложения, так как API Level системы (6) теперь выше, чем максимальный уровень, который может поддержать приложение (5). Система делает приложение невидимым для пользователя, и удаляет его из устройства.
Предупреждение: использование этого атрибута не рекомендуется. Во-первых, нет никакой потребности установить этот атрибут как средство блокирования развертывания Вашего приложения на новые версии платформы Android по мере их появления. Для Android декларируется полная обратная совместимость старых приложений для новых версий Android. Ваше приложение должно работать должным образом на всех новых версиях, если оно использует только стандартное API и следует лучшим правилам и практикам разработки. Во-вторых нужно помнить, что применение этого атрибута приведет к автоматическому удалению Вашего приложения с устройств пользователя, которые обновят свою систему на более высокий API Level, чем указано в атрибуте. Большинство устройств, на которых вероятно будет установлено Ваше приложение, получают периодические обновления системы на лету, по воздуху (over the air), так что Вы должны учитывать этот эффект перед тем, как установить этот атрибут для своего приложения.
Будущие версии Android (вне Android 2.0.1) больше не будут проверять maxSdkVersion и принудительно применять его значение при установке или проверке совместимости приложения. Однако Google Play продолжит использовать этот атрибут как фильтр при предоставлении приложений, доступных для закачки пользователям.
[Пример установки версии приложения при создании проекта в Eclipse]
В Eclipse при создании проекта запускается мастер, который на первом экране позволяет настроить параметры, касающиеся версии приложения.
Поле Minimum Required SDK определяет значение атрибута android:minSdkVersion будущего приложения. Здесь желательно указать версию достаточно популярной платформы, которая возможно уже несколько устарела.
Поле Target SDK задает атрибут android:targetSdkVersion. Укажите здесь версию системы, с которой Вы тестировали Ваше приложение. К примеру, Вы отлаживаете программу на версии Android 4.1.2, тогда в выпадающем списке Target SDK нужно выбрать API 16: Android 4.1 (Jelly Bean).
Поле Compile With задает версию SDK, на котором Ваше приложение будет скомпилировано. Задайте здесь максимальную (самую свежую) на текущий момент версию системы Android.
Версионность веб-приложений
Общеизвестно, что каждый программный продукт в конечном итоге обретает номер поставляемой версии. Изначально это может быть цифра в README файле, на борде в JIRA либо просто в голове у тимлида или ПМа. Но в какой-то момент становится понятно, что нужно формализовать процесс назначения версии релизу, отобразить номер в приложении, интегрировать версионность в CI, аналитику и другие места.
С появлением технологии PWA, версионность в вебе обрела еще больший смысл, ведь теперь самая последняя версия приложения доступна пользователю не в момент загрузки страницы, а только через определенное время после обновления файлов в фоновом режиме. Поэтому важно следить за номерами версий у пользователей, чтобы знать в какой из них возникла проблема и сколько обновилось до последней.
Ниже рассмотрим способы добавления версионности веб-проекту, используя готовые решения, и напишем свой универсальный скрипт, удовлетворяющий всем требованиям.
Git и версионность
Для наглядности, давайте взглянем на диаграмму одного из самых популярных подходов Git Flow:
Демонстрация Git Flow
Расшифровка версии semver
Очевидно, что версии в первую очередь должны быть привязаны к коммитам (после которых и собираются релизные сборки), чтобы хранилась наглядная история релизов и легко было откатываться до предыдущего при необходимости. Удобнее всего это реализовать с помощью тегирования коммитов (git tag). Давайте рассмотрим npm пакеты, помогающие решить эту задачу.
Готовые npm-решения
Основная проблема в том, что все существующие npm пакеты предназначены больше для версионности и публикации вашего проекта в npm непосредственно, хотя никто не мешает воспользоваться функционалом инкрементирования версии сборки и пуша тегов в гит (будь то ручной запуск команды, либо из CI-скрипта).
Примеры:
Обновление версии с помощью одной команды
Нет возможности контролировать, куда записывается номер версии (только в package.json)
Нет возможности добавить постфикс версиям (например, 1.3.1-dev, 0.1.1-alpha)
Не все git сервисы разрешают пушить тег с новой версией и измененный package.json в репозиторий прямо из CI-скрипта после окончания сборки.
Пакет популярнее предыдущего, больше конфигураций, интерактивный режим настройки. Принцип выполнения команды такой же:
Для режима CI нужно добавить флаг —ci
Нет возможности добавить постфикс к версии (по крайней мере я не нашел)
Наиболее популярный из представленных примеров. Полностью автоматизирует процесс версионности, убирая человеческий фактор по инкременту версий. Однако, для этого необходимо следовать Commit Message Conventions (хороший повод начать именовать коммиты более организованно).
Вдобавок, на основе коммитов генерируется changelog.
Возможность контролировать процесс обновления мажорных и минорных версий вручную.
Как видим, готовых решений достаточно, однако, давайте все же попробуем написать свое, адаптировав его под свои нужды.
Что нам нужно?
Код из git-веток попадающий на окружение (dev, staging, prod) должен быть пронумерован и хранить тип окружения (к примеру, 1.0.1-dev)
Каждый пуш в ветку (master, integration, release) увеличивает патч-версию
Обновление мажорной и минорной версии происходит вручную после каждого релиза / спринта. Какую версию менять решаем сами на основе запланированных задач и потенциальных изменений
Версия сборки доступна в JS, для того чтобы была возможность ее отображать в самом приложении, использовать для аналитики, передавать в системы репорта ошибок и т.п.
package.json не должен меняться во время CI (т.е версию приложения не храним в этом файле) во избежание потенциальных мерж конфликтов (к примеру, когда одновременно вмерживается несколько реквестов и сборки собираются одновременно, в нашей команде такое случается достаточно часто).
При релизе патч-версия (z) начинается с 1, оставляя только номер релиза (x.y). Например: версии на деве 1.4.1-dev, 1.4.2-dev, 1.4.3-dev, а в релиз пойдет 1.4.1. Если же подливаем hotfix в тот же релиз, то версия будет 1.4.2.
Данные пункты являются субъективными и легко могут быть изменены под ваши требования. Ниже рассмотрим JS-реализацию данной логики.
Реализация своей системы версионности
Предварительно создадим 2 файла, первый version.txt (в корне проекта) для хранения мажорной и минорной версии релиза (которые мы вручную меняем, как указано выше). В файле будет хранится только 2 числа версии, разделенные точкой вида: 2.13
Это позволит получить доступ к версии прямо во время выполнения javascript / typescript кода приложения и использовать по назначению:
Логика определения и назначения версии будет следующая:
получить текущую мажорную и минорную версии (x.y) из файла version.txt
вывести список всех git-тегов данного релиза x.y.*
обнаружить патч версию (z) последнего тега релиза
добавить новый тег вида x.y.(z+1)
при необходимости добавить постфикс окружения (x.y.z-dev)
Скрипт генерации новой версии приложения на основе предыдущих версий из git готов. Далее можно запускать сборку проекта, зная, что app-version.js с новой версией попадет в проект и будет доступен в JS.
Создаем еще один файл push-new-version-tag.js:
Готово. Остается добавить запуск этих команд в ваш CI скрипт.
А вот как выглядит наш для GitLab (проект на Angular):
Как мы используем номер версии в Uxcel?
Наше приложение является PWA, поэтому нам важно следить за номерами версий наших пользователей: версии отправляются в google analytics, в систему мониторинга ошибок sentry, в API запросы (которые могут обрабатываться по-разному в зависимости от версии) и, само собой, версия отображается в самом приложении. Помимо этого, номер версии может использоваться для отображения Release Notes или для показа обучающего окна нового функционала сразу после авто-обновления приложения.
Спасибо за внимание, надеюсь, статья была полезной для вас! Буду рад услышать ваше мнение, делитесь своими способами версионности веб-приложений.
8 приложений для Android, которые нужно удалить. Они опасны
Кто бы что ни говорил, но Google Play – это помойка. Не даром её признали самым популярным источником вредоносного софта для Android. Просто пользователи в большинстве своём доверяют официальном магазину приложений Google и скачивают оттуда любое ПО без разбору. А какой ещё у них есть выбор? Ведь их всегда учили, что скачивать APK из интернета куда опаснее. В общем, это действительно так. Но остерегаться опасных приложений в Google Play нужно всегда. По крайней мере, постфактум.
Есть как минимум 8 приложений, которые нужно удалить
Google добавила в Google Play функцию разгона загрузки приложений
Исследователи кибербезопасности из антивирусной компании McAfee обнаружили в Google Play 8 вредоносных приложений с многомиллионными загрузками. Попадая на устройства своих жертв, они скачивают получают доступ к сообщениям, а потом совершают от их имени покупки в интернете, подтверждая транзакции кодами верификации, которые приходят в виде SMS.
Вредоносные приложения для Android
Нашли вирус? Удалите его
В основном это приложения, которые потенциально высоко востребованы пользователями. Среди них есть скины для клавиатуры, фоторедакторы, приложения для создания рингтонов и др.:
Это названия пакетов приложений, то есть что-то вроде их идентификаторов. Поскольку всё это вредоносные приложения, их создатели знают, что их будут искать и бороться с ними. Поэтому они вполне могут быть готовы к тому, чтобы менять пользовательские названия приложений, которые видим мы с вами. Но это мы не можем этого отследить. Поэтому куда надёжнее с этой точки зрения отслеживать именно идентификаторы и удалять вредоносный софт по ним.
Как найти вирус на Android
Но ведь, скажете вы, на смартфоны софт устанавливается с пользовательскими названиями. Да, это так. Поэтому вам понадобится небольшая утилита, которая позволит вам эффективно выявить весь шлаковый софт, который вы себе установили, определив название их пакетов.
В красном квадрате приведен пример названия пакета
Package Name Viewer удобен тем, что позволяет не просто найти нужное приложение по названию его пакета, но и при необходимости перейти в настройки для его удаления. Для этого достаточно просто нажать на иконку приложения, как вы попадёте в соответствующий раздел системы, где сможете остановить, отключить, удалить накопленные данные, отозвать привилегии или просто стереть нежелательную программу.
Как отменить подписку на Андроиде
Лучше всего приложение именно удалить. Это наиболее действенный способ защитить себя от его активности. Однако не исключено, что оно могло подписать вас на платные абонементы, поэтому для начала проверьте свою карту на предмет неизвестных списаний, а потом просмотрите список действующих подписок в Google Play:
Если подписка оформлена через Google Play, отменить её ничего не стоит
В принципе, если подписка была оформлена через Google Play и оплата уже прошла, вы можете потребовать у Google вернуть уплаченные деньги. О том, как это делается, мы описывали в отдельной статье. Но поскольку разработчики таких приложений обычно тщательно продумывают способы воровства денег, как правило, они не используют встроенный в Google Play инструмент проведения платежей, чтобы их в случае чего не могли отозвать.
«Приложение не делает ничего»: разбор App List от Минцифры — малоизвестной программы, предустановленной на Android Статьи редакции
App List есть на смартфонах и планшетах, продаваемых в России с 1 апреля 2021 года. Минцифры планирует и дальше его развивать, но эксперты считают, что приложение никому, кроме чиновников, не нужно, а пользователи ставят ему низкие оценки в Google Play.
6 апреля 2021 года информационное агентство ТАСС сообщило, что министерство цифрового развития, связи и массовых коммуникаций опубликовало в Google Play приложение App List (также упоминается под названиями Applist и Applist.ru). Программа, как писало агентство, представляет собой каталог других приложений, в том числе сервисов «социально значимых» российских сайтов. В Минцифры России пояснили vc.ru, что приложение App List разработано по инициативе самого министерства.
С 1 апреля 2021 года App List и другие российские программы для iOS и Android обязательны для предустановки на смартфоны и планшеты, которые продаются в России.
Причина создания App List изложена в постановлении правительства об обязательной установке программ в ноябре 2020 года. В документе за подписью премьер-министра Михаила Мишустина дано описание целого класса приложений: программы доступа к «социально значимым ресурсам» и «к списку российских программ, быстро набирающих популярность». Под это описание подходит приложение App List от Минцифры и, отчасти, «Куб!» компании «Вымпелком» (оператор связи «Билайн»).
Весной 2020 года, за год до анонса App List, «Билайн» выпустил приложение «Куб!» для iOS и Android. Приложение содержало ссылки на 300 социально значимых российских сайтов. В конце 2020 года компания закончила эксперимент, а затем удалила «Куб!» из магазинов приложений. Представитель «Билайна» проигнорировал вопросы обозревателя vc.ru в одном из мессенджеров.
Обновлено 18 августа: представитель «Билайна» сообщил vc.ru, что компания планирует использовать опыт, полученный во время эксперимента с приложением «Куб!», в своих будущих проектах.
Приложение «Куб!» было своего рода экспериментом для нашей компании. Мы понимали, что людям необходимо предоставить бесплатный доступ к социально значимым ресурсам, особенно, в период пандемии, в отсуствие возможности физического посещения МФЦ или других организаций. Поэтому в нашем приложении для абонентов в сети «Билайн» в России трафик на эти ресурсы не тарифицировался.
В настоящий момент эксперимент завершен, но мы учтем опыт, полученный в результате работы над этим продуктом, и будем использовать его в наших будущих проектах.
Таким образом, создание App List, или «Каталога лучших мобильных приложений на русском языке», как сказано в описании программы в Google Play, — результат сразу двух государственных инициатив в области ИТ. Первая инициатива — это эксперимент по бесплатному доступу пользователей к «социально значимым» сайтам в интернете (проект «Доступный интернет»), а вторая — закон об обязательной предустановке российского ПО.
Бесплатный доступ к социально значимым сайтам по проекту «Доступный интернет» дают крупнейшие операторы связи. Эксперимент стартовал 1 марта 2020 года. За месяц до его начала операторы публично оценили свои убытки в 150 миллиардов рублей в год.
Минцифры ответило на критику только через полгода, в сентябре 2020: чиновники заявили, что убытки операторов возмещаться не будут, а проект продолжится. Министерство продлило эксперимент до 1 декабря 2021 года.
16 августа 2021 года Минцифры разместило на сайте нормативных правовых актов проект постановления «Об утверждении Правил оказания услуг связи по передаче данных». Согласно документу, операторы будут обязаны открыть россиянам бесплатный доступ к социально значимым сайтам. В пояснительной записке сказано. что проект не требует дополнительного бюджетного финансирования.
У App List есть две цели, предположил в разговоре с vc.ru генеральный директор Института исследований интернета Карен Казарян:
За пределами этих применений я не вижу какой-либо другой перспективы данного приложения.
Приложение App List опубликовано в Google Play 17 февраля 2021 года. По словам представителя Минцифры, разработкой и сопровождением приложения App List занимается «РТ Лабс», дочерняя компания «Ростелекома». App List стал доступен для загрузки в четвертом квартале 2020 года, отметили в министерстве.
App List представляет собой простейшую программу: это каталог с краткими описаниями и иконками других приложений для Android и ссылками, ведущими в магазин Google Play. В программе нет лицензионного соглашения и формы для связи с разработчиками.
Найти что-то в App List с помощью поисковой строки можно только если заранее знать название нужной программы. Обозреватель vc.ru убедился в этом лично: если в строке поиска ввести запрос «голосовой помощник», в результате не будет ни одной рекомендации, хотя в App List есть приложения с голосовыми ассистентами от «Яндекса» и «Сбера». Поисковый движок «каталога лучших мобильных приложений» полностью игнорирует описания приложений в своем собственном каталоге.
Кроме того, обозреватель vc.ru на личном опыте убедился, что пользователь не установит российское ПО из каталога App List при отрицательном балансе лицевого счета за интернет, как задумали чиновники. Google Play и альтернативные магазины приложений при отрицательном балансе не загружаются – возможно потому, что их нет в списке социально значимых сайтов.
В последней версии списка «обязательных» российских приложений от 31 июля 2021 года написано, что App List в 2022 году будет предустановлен только в устройствах на Android, а приложение для iOS не упоминается. Хотя в первом перечне, который вышел 31 декабря 2020 года, агрегатор Applist.ru описывали как приложение для Android и iOS.
Исполнительный директор Общества защиты интернета Михаил Климарёв предположил, что Apple отказалась добавить App List в список приложений, которые iOS предлагает пользователям установить при первом включении iPhone после покупки. Вместо этого компания отправила Минцифры в App Store, но и там министерство получило отказ, считает эксперт: потому что в правилах магазина якобы написано, что агрегаторы других приложений не пропускают.
По данным Google Play, приложение App List было установлено более одного миллиона раз, и при этом получило на момент выхода этого материала всего 252 оценки пользователей с общим рейтингом 3,2 балла из 5 возможных. Климарёв считает, что соотношение количества установок и оценок приложения может свидетельствовать о накрутке статистики.
«Обычно отзывы оставляют 10% пользователей, эти люди при установке хотя бы звёздочки ставят. От одного миллиона 10% — это, извините меня, 100 тысяч [оценок] должно быть, а тут всего 246 (столько оценок было в Google Play во время разговора vc ru с директором ОЗИ)», — рассуждает Климарёв.
В ОЗИ выяснили, что подогнать статистику до нужных показателей можно за сравнительно небольшие деньги: цена одной установки приложения на рынке накруток и ботов варьируется в диапазоне от 3 до 10 рублей.
У специалистов возникают вопросы по поводу безопасности приложения App List. Директор АНО «Инфокультура» Иван Бегтин в своей рассылке на Substack указывал, что российское приложение может отправлять данные иностранным компаниям с помощью встроенных трекеров Google Crashlytics и Google Firebase.
Это два облачных сервиса от Google, которые позволяют ускорить разработку мобильных приложений за счёт готовых решений по отладке, сбору данных и обмену сообщениями, объяснил Бегтин vc.ru. Он отметил, что все данные, которые собирают эти сервисы, Google хранит за пределами России.
В виду специфики данных, на серверах Google из Crashlytics и Firebase могут накапливаться весьма чувствительные личные данные, например, сведения медицинского характера в персонализированных COVID-19 приложениях или же сведения личной переписки, если она ведётся через инфраструктуру Google Firebase.
По словам представителя Минцифры, приложение App List не собирает данные пользователей.
Во время разговора с vc.ru Михаил Климарёв изучил разрешения App List и сказал, что не видит в «каталоге лучших программ» не только потенциальных угроз безопасности, но и пользы: «Это приложение, которое не делает ничего. Еще раз: приложение, которое не делает ничего — это App List», — сказал Климарёв.
Список социально значимых сайтов и их дочерних сервисов, которые доступны в каталоге App List, ведет Минцифры. Также в приложение добавлены набирающие популярность сервисы, но какие именно относятся к этой категории, в постановлении правительства о предустановке российских программ не разъясняется.
В App List могут попасть программы, быстро набирающие популярность — существующие меньше года и успевшие набрать более 100 тысяч пользователей. Перечень программ, включенных в App List, сформирован и не будет изменяться до 1 января 2022 года.
В списке социально значимых сайтов 391 доменное имя. В него вошли сайты крупнейших государственных компаний, банков, социальные сети и сообщества, агрегаторы новостей, СМИ и развлекательные сайты, интернет-магазины, сайты по поиску работы, сайты медицинских компаний, а также волонтерских объединений.
В каталоге App List есть далеко не все официальные приложения сайтов из этого списка. Неполноту каталога заметили пользователи Google Play.
«Количество программ в AppList меньше, чем информационных ресурсов в указанном приказе, так как не все информационные ресурсы имеют мобильные приложения», — пояснил vc.ru представитель Минцифры.
О процедуре отбора приложений в каталог App List мало что известно. Министерство никогда не публиковало инструкций для разработчиков. По словам Карена Казаряна, «каталог лучших приложений» может пополняться в заявительном порядке:
Для попадания в каталог, считают четыре из пяти опрошенных vc.ru ИТ-экспертов, нужно быть оператором сайта из списка социально значимых, либо быть владельцем набирающего популярность приложения. В Минцифры эту информацию подтверждают, но порядок пополнения каталога не разъясняют.
Однако даже операторы социально значимых сайтов и сервисов ничего о процедуре отбора в App List не знают. Так, в «Яндексе» рассказали vc.ru, что компания не подавала заявок на добавление её приложений в App List. Компании-операторы двух других популярных приложений из каталога отказались от комментариев, но их представители отметили в беседе с обозревателем vc.ru, что о процедуре отбора им ничего не известно.
Кроме того, некоторые компании не следят за статистикой переходов из App List. «Мы не отслеживали специально, повлияло ли попадание в каталог на скачивания нашего приложения», — сообщил vc.ru представитель Skyeng.
Мы не оцениваем скачивания наших приложений из AppList — механизм установки из этого каталога ничем не отличается от обычной установки приложения из Google Play. Пользователь может кликнуть на понравившееся приложение, после этого его переадресуют в Google Play для дальнейшего скачивания и установки.
Михаил Климарёв считает, что App List и подобные предустановленные приложения не могут помочь с привлечением пользователей. «Предустановка на устройство — это расширение воронки (аудитории — vc.ru), и это круто. Но оно должно быть грамотным. А [если] на дорогущее устройство от Samsung впихнули Mail.ru, я всё равно не буду им пользоваться, не моё это. Ниша-то не та», — рассуждает он.
Представители Минцифры в своём комментарии ответили не на все вопросы vc.ru. В частности, министерство не раскрыло бюджет проекта App List. Кроме того, без ответа остались вопросы о редких обновлениях и модерации приложения.
Большинство комментариев пользователей Google Play под App List — критические и издевательские. Авторы отзывов называют приложение бесполезным, обвиняют разработчиков в продвижении коммерческих продуктов и призывают удалять вошедшие в каталог App List приложения.
