Эксперты google не проверяли это приложение
В середине мая по стору прокатилась волна автоматических банов, связанных с упоминанием вирусов в контенте самых разных продуктов. Наше приложение со 180 тысячами активных пользователей оказалось под угрозой. Из двух попыток его спасти мы честно завалили одну.
В итоге все закончилось хорошо, но это не первая подобная волна: и мы решили поделиться алгоритмом действий, которые вы можете предпринять, если окажетесь в подобной ситуации — особенно если производите свой контент.
На почту, связанную с нашими аккаунтами в сторах, пришло «письмо несчастья».
Красочно оформленный шаблон сообщал, что приложение для изучения английских слов заблокировали «согласно пункту 8.3 правил для разработчиков, так как приложения, упоминающие COVID-19 или связанные термины, могут быть допущены в маркет, только если они изданы или авторизованы государственными органами или организациями системы здравоохранения».
Почта no-reply как бы намекает. На деле, для апелляций есть другой канал, иногда там даже отвечает человек.
В самих правилах для разработчиков не было списка тех самых «связанных терминов» или рекомендаций на этот счет. Конкретных ссылок или скринов из нашего приложения, нарушающих правила, Google также не приложил. А пункт 8.3, на который ссылается письмо, был максимально размыт: по сути, «вас могут заблокировать по любому подозрению в нарушении любого применимого законодательства или любых применимых политик».
Но коронавирус как источник всех бед был указан достаточно четко. В условиях решений властей о борьбе с фейк-ньюс о вирусе команда стора могла перестраховаться и превентивно забанить все случаи, хоть как-то подходящие под алгоритм. То, что наш контент анализировал бот, было понятно сразу. Также было понятно, что какие-то упоминания коронавируса могли быть в материалах.
Когда вокруг в режиме 24/7 говорят только о нем, а у вас есть отдел, обновляющий контент для приложения и соцсетей, вполне вероятно, что ребята обыграют эту ситуацию.
- Стали искать упоминания аналогичных случаев в сети — они были, но готовых рецептов не было ни у кого. Зато мы поняли, что история реально массовая.
- Стали искать контакты в Гугле: через знакомых, знакомых знакомых из индустрии и т.д. Сразу получили от них несколько инсайтов, например: «Все в итоге признают, что что-то сделали не то. 100% где-то накосячили. Могли смайлик не тот поставить — и это повод». Стали присматриваться к мелочам: вплоть до иконок, эмодзи и деталей иллюстраций.
- Договорились с контент-командой, что на случай ребята воздержатся в соцсетях от публикации видео, статей или сторис, где может упоминаться тема коронавируса (например, советы по дистанционному обучению в период пандемии). Эти материалы в нашем случае могут подтянуться в приложение.
- Написали по каналу, предназначенному для апелляций: признали, что мы не имеем отношения к государственным органам и сектору здравоохранения, что какие-то термины могли использоваться и вот это все. Попросили деталей. В ответ получили совет: «Уберите любые связи с коронавирусом из метаданных: названия приложения, описания, примечаний к релизу, либо скриншотов».
Проверили контент приложения: и нашли косяк в метаданных.
Помогите ребятам найти, где они накосячили)
Если тоже не разглядели сразу, приблизим:
Мелкая деталь на картинке на скринах в сторе = два дня развлечений для всей команды.Мы выпилили эту картинку, также на случай убрали из приложения ссылки на статьи, видео и сторис с упоминанием обучения на карантине, самоизоляции, волонтерства и помощи врачам в период пандемии — деактивировали старый и залили новый билд по инструкции, но …
В 6 утра 14 мая история продолжилась — новый билд зареджектили. У нас осталась одна попытка до полной блокировки девелоперского аккаунта. Но спасибо Гуглу, что хотя бы не разослал текущим пользователям пуши с советом удалить версию приложения, установленную до блокировки (по правилам он так может).
Вишенка на торте: мы потеряли возможность заливать исправления. Осталась только апелляция по почте.
Тогда же появилась новая зацепка, которая навела на мысль, что проблема может быть масштабнее: мы поняли, что бот может ходить в наш словарь.
График заражений в Германии из новостей как иллюстрация к слову “ситуация”.Словарь мог содержать десятки, если не сотни иллюстраций или слов, хоть как-то относящихся к теме: «пандемия», «маска», «социальная дистанция» и тому подобное. Были и более «очевидные» вещи.
Ради интереса, вбейте «вирус» в поиск по картинкам в любимом поисковике — и получите очень похожий результат. «Это жизнь такая» (с)При этом тренировка слов — одна из ключевых фишек приложения. Пообещать выпилить ее не вариант: это как обещать отпилить себе ногу, чтобы вас допустили к марафону.
Но если не найти решение, потеряем 180к активных пользователей, их историю, оценки и т.д.
Стали действовать на ощупь:
- По аналитике поняли, по каким частям приложения ходили боты. Это один из вариантов локализовать возможные проблемы. Узнали, что боты заходили в словарь, видео и уроки.
- Включили режим параноика. Решили собрать все возможные слова и уроки, которые могли быть хоть как-то связаны с темой медицины, карантина и пр. Также собрали все потенциально опасные внешние ссылки в разделе видео. Внутренний параноик также говорил: «А что, если мы покажем пользователю ничего не нарушающее видео с Youtube, а в рекомендациях к тому видео всплывет…», — поэтому в итоге скрыли видео совсем.
- Сделали свой список из 9 очень опасных слов («пандемия», «вирус» и пр.), 50+ потенциально опасных слов (официального списка нет, так что включаем фантазию) и 900+ мест, где они упоминались. Скрыли весь этот контент. Опции «скрыть по параметрам» в админке, откуда брался контент, не было — мы срочно дописали ее для этого случая.
- Убрали ссылки на социальные сети, потому что мало ли что будет опубликовано там, — параноик-мод был по-прежнему включен на полную.
А параллельно составляли вторую версию апелляции, стараясь максимально разжевать и аргументировать.
- Рассказали, что наше приложение используется для дистанционного обучения , которое особенно актуально во время карантина. Еще раз признали, что по этой причине у нас могут встречаться потенциально связанные с COVID ключевые слова — в контексте образования.
- Приложили все возможные пруфлинки на связь продукта и компании с образованием: образовательную лицензию, ссылки на упоминания в крупных СМИ в нужном контексте, упоминание в списке социально-значимых информационных ресурсов, составленном Минкомсвязи… В общем, всё, что может иметь хоть какой-то вес.
Отправили по официальному каналу, а также продублировали обращение на внешнем форуме Google Play и ресурсах для Android-разработчиков.
Сначала нам написали, что изучают апелляцию и приложенные документы. Еще через день нам разблокировали страницу разработчика и дали возможность восстановить приложение. Мы залили билд, в котором было по-максимуму отключено все… И прошли проверку!
Честно, до сих пор не знаем, что из этого сработало. И едва ли нам об этом скажут прямо, но на будущее посоветуем себе и всем:
- Первые ответы на обращения могут присылать роботы (есть такое подозрение), потом вы прорветесь к человеку. Конкретных деталей он не даст, но в целом вести переговоры по официальному каналу — все, что вы можете.
- Будьте предельно конкретны и открыты: рассказывайте той стороне о шагах, которые предпринимаете, чтобы разрешить ситуацию, спрашивайте уточнений на основе уже предпринятых шагов. А также сразу старайтесь рассказать как можно больше хорошего о себе и погрузить в контекст продукта.
- Сразу продумывайте разные версии и причины — вплоть до жалоб конкурентов. Что могло стриггерить? А что еще? Лучше перебдеть и побыть неделю параноиком, а потом постепенно убрать ненужные ограничения в новых билдах, чем потерять на время доступ к аккаунту разработчика — а то и все, что было связано с аккаунтом. У вас есть максимум пара попыток: лучше тратить их с умом, как желания у джинна.
P.S. Спустя две недели мы узнали, что наше приложение попадает под категорию «Eligible COVID-19 apps». Этим приложениям можно использовать контент, в котором коронавирус упоминается вне связи с медициной. Например, анализировать экономический и социальный эффект, давать советы, как лучше проводить самоизоляцию и т.д.
Подробности можно почитать в публичном разъяснении Google — но мы пока решили придерживаться выработанных командой критериев и модерировать контент в приложении.
Чтобы обеспечить безопасность пользовательских данных, Google тщательно проверяет все приложения, которые используют restricted API scopes и имеют доступ к Google User Data. Не так давно мы в Snov.io прошли через процесс проверки и получили одобрение Google, с чем и хотим поделиться.
Новые правила для приложений
9 октября 2018 года Google анонсировал новые правила для приложений, которые используют Google restricted API scopes. Они включали в себя 2 этапа проверки:
- Проверка соответствия приложения политике Google API User Data
- Проверка соблюдения минимальных требований безопасности
The restricted scope app verification verifies compliance with the Google API User Data Policy and an additional set of policies outlined in Additional Requirements for Specific API Scopes. First, your application will be reviewed for compliance with the Google API Services: User Data Policy. Thereafter, you will have the remainder of 2019 to demonstrate compliance with the secure handling requirements.
Проверка соблюдения минимальных требований безопасности стоила немалых средств — от $15,000 до $75,000.
Assessments will be conducted by a Google-designated third-party assessor, may cost between $15,000 and $75,000 (or more) depending on the complexity of the application, and will be payable by the developer. This fee may be required whether or not your app passes the assessment.
Уже 9 января 2019 года Google ужесточил правила для приложений, которые планируют использовать Google API. Для приложений, которые использовали Google API ранее, появилось требование подать заявку на верификацию до 15 февраля. В противном случае доступ к приложению был бы закрыт для новых пользователей начиная с 22 февраля, а действующие пользователи не смогли бы использовать приложение с 31 марта.
Последствия такого развития событий были бы малоприятными. Связано это с тем, что значительное количество наших пользователей (а их больше 100 тысяч) используют Gmail. Следовательно, мы бы просто потеряли этих клиентов.
For projects that require action, you must submit apps for verification before Feb 15th, 2019. If you don't, access for new users will be disabled on February 22nd, 2019, and existing grants for consumer accounts will be revoked on March 31st, 2019.
Как у нас всё происходило до обновлений
Наша платформа Snov.io использует Google API с 2017 года. Наше приложение использовало несколько restricted scopes: для чтения входящей почты и для работы с черновиками.
Google и раньше проверял приложения, которые используют Google API. Для того, чтобы применить новый API scope, нужно было добавить его в консоли и указать, для чего именно он будет использован. Пока сотрудники Google проверяли заявку, пользователи видели на своих экранах уведомление «This app isn’t verified»:
Обычно данная проверка занимала у нас 2-3 рабочих дня (хотя, в письме от Google было указано, что процесс может длится до 7 дней) и всегда проходила без проблем. Мы дожидались пока Google проверит нашу заявку и только потом заливали фичу на прод для того, чтобы пользователи не видели уведомление «This app isn’t verified».
Прохождение первого этапа
Для начала мы решили сосредоточиться на первом этапе проверки, а именно — соответствии нашего приложения политике Google API User Data.
16 января в Google консоли появилась кнопка Подать на верификацию и мы отправили заявку. Перед отправлением мы удостоверились, что соответствуем всем пунктам политике Google API User Data. Мы внесли изменения в нашу политику конфиденциальности, в частности, добавили раздел Google User Data, где подробно описали, какие данные, полученные от Google API, мы храним, как их используем и когда удаляем.
12 февраля мы получили ответ на отправленную заявку. Нас просили записывать видео и показывать, как мы используем запрашиваемые restricted API scopes.
В итоге, нам пришлось отказаться от двух наших проектов на Google Cloud и объединить их в один. Мы отказались от первого проекта для тестового сервера, который работал в тестовом режиме, и использовали для теста тот же проект, что и на проде. Второй проект для авторизации в систему через Google мы также удалили и вместо него использовали для входа тот проект, который требовал верификацию.
Нам, например, сделали замечание, что мы используем для входа в систему приложение с одним ID, а при подключении email аккаунта — приложение с другим ID. Мы сделали это намеренно, так как это две совсем разные функции. Приложение для входа в систему не требовало никаких проверок и мы не хотели, чтобы непрохождение проверки приложения с restricted API scopes привело к отключению приложения для верификации.
20 апреля мы наконец-то прошли первый этап проверки на соответствие Google Data Policy!
Прохождение второго этапа
Шаг 1. Выбор компании для прохождения проверки
Ко второму этапу проверки нашего приложения Google прислал контакты двух компаний на выбор — Bishop Fox и Leviathan Security. Пройти проверку можно было только у них. Дедлайн был дан до 31 декабря.
20 мая мы отправили письма двум независимым экспертам для прохождения проверки. Bishop Fox и Leviathan Security прислали анкеты с вопросами о нашем приложении. Нужно было ответить, какие Google данные мы используем, какое количество строк кода прописано для каждого языка программирования, а также на вопросы о нашей инфраструктуре, процессе развертывания ПО и хостинг провайдере. Мы всё заполнили и начали ждать предложения с ценой.
В ходе подготовки и предварительного общения с представителями компаний мы узнали, что хостинг, на котором размещены наши сервера, не соответствует SOC2. И для успешного прохождения проверки нам нужно было переехать на соответствующий SOC2 хостинг. Мы уже давно думали о переезде на Amazon, поэтому параллельно начали процесс переезда.
Мы также узнали, что нужна программа Bug Bounty, предлагаемая многими веб-сайтами и разработчиками ПО. С её помощью люди могут получить признание и вознаграждение за поиск ошибок, в особенности тех, которые касаются эксплойтов и уязвимостей.
В сентябре у нас было два готовых контракта от Bishop Fox и Leviathan Security. Мы должны были определиться, с кем заключать контракт. По каким критериям выбирать эксперта мы не знали, но договор с Leviathan Security показался нам более прозрачным, несмотря на то, что стоил он незначительно дороже.
Шаг 2. Подписание договора и подготовка к проверке
8 октября мы подписали договор с Leviathan Security. На момент подписания договора мы еще не завершили процесс переезда на Amazon. Поэтому в нашем договоре в графе «хостинг» остался пробел и мы должны были вписать его позже.
Также мы узнали, что будет включать в себя проверка:
- External Network Penetration Test
- Application Penetration Testing
- Deployment Review
- Policy & Procedure Review
- Preparation
- Assessment
- Verification & Validation
- Final Report
23 октября Leviathan Security прислал анкету Self-Assessment Questionnaire (SAQ). Вместе с ней мы также предоставили наши политики, которые нужны были для прохождения проверки:
- Incident Response Plan: Establishes roles, responsibilities, and actions when an incident occurs
- Risk Management Policy: Identifies, reduces, and prevents undesirable incidents or outcomes
- Vulnerability Disclosure Policy: Provides a means for external parties to report vulnerabilities
- Information Security Policy: Ensures that all users comply with rules and guidelines related to the security of the information stored digitally at any point in the network
- Privacy Policy: Ensures that users can delete their accounts and related user data by demonstrating an account deletion if relevant
На митинге мы узнали, что нам необходимо шифровать Oauth токены с помощью KMS, чего мы до этого не делали. Также мы обсудили приблизительное время нашей проверки. Нас заверили, что если ее назначат на конец года и мы не будем успевать пройти ее, Leviathan Security будет вести переговоры с Google, чтобы нам продлили дедлайн.
14 ноября мы получили информацию о планируемом старте нашей проверки: поздний декабрь или ранний январь. И Leviathan Security предупредил Google, что мы можем предоставить LOA позднее дедлайна.
16 ноября мы получили подтверждение от Google о переносе дедлайна до 31 марта.
Шаг 3. Проверка
13 декабря мы получили письмо, в котором нас оповестили о начале проверки — 2 января, и попросили выполнить следующие требования:
1. Подтвердить возможность проведения проверки.
2. Еще раз предоставить необходимую информацию.
Документы нужно было загрузить в общую папку на OneDrive за неделю до проверки — до 26 декабря. Мы не предоставляли никаких дополнительных документов кроме обязательных:
- Incident Response Plan
- Risk Management Policy
- Vulnerability Disclosure Policy
- Information Security Policy
- Privacy Policy
- Supporting Privacy Documentation
- Terms and Conditions
- Self Assessment Questionnaire (SAQ)
- документация к внешним API методам
- тестовые аккаунты для приложения
- список внешних URL-адресов
- высокоуровневая диаграмма нашей архитектуры
- список IP основных компонентов
3. Предоставить доступ к исходному коду.
4. Пригласить определенных людей в мессенджер Slack.
5. Указать номер телефона и детали для эскалации проекта.
6. Предоставить информацию о том, как нам должны выставить счет.
7. Сообщить командам внутренней безопасности, CDN и хостинг провайдерам, что проверка состоится с 2 января по 27 января.
8. Создать общую папку на OneDrive.
9. Ознакомиться с часто задаваемыми вопросами Google проверки.
30 декабря состоялась кик-офф встреча, на которой было почти всё то же самое, что и на первом митинге. Мы представились, описали продукт с комплектом технологий и подтвердили, что наша система стабильная, и что во время оценивания продукта никаких крупных релизов выходить не будет. Закончилось всё вопросами и комментариями.
2 января началась проверка безопасности. Отметим, что проходила она без особых трудностей. Иногда было неудобно из-за разницы в часовых поясах — все созвоны и общение в Slack мы проводили уже в нерабочее для нас время.
В основном уязвимости были связаны с устаревшими методами шифрования пользовательских данных и недостаточным логированием. К нашим документам по политике претензий не было. Отдел политики Leviathan Security задал несколько уточняющих вопросов и сказал, что выглядят они солидно.
Недостатка в общении не было. Все неясные вопросы мы могли прояснить на статус митингах или в Slack. Репорты об уязвимостях были хорошо описаны, а также содержали рекомендации к исправлению. В последний день нашего оценивания все критичные, высокие, а также некоторые средние и низкие уязвимости были исправлены и проверены.
31 января мы получили LOA и отправили его Google представителям.
11 февраля получили подтверждение прохождения проверки от Google.
Для нас самым сложным была неизвестность. Чего ожидать? Как все будет происходить? Мы чувствовали себя первопроходцами. Нигде не было никакой информации о том, как другие компании проходили эту проверку, что и подтолкнуло нас к тому, чтобы поделиться информацией о Security Checkup с другими.
Тем, кому такая проверка только предстоит, хотим сказать, что она не так страшна как может казаться. Да, процесс — трудоемкий, но на исправление всех уязвимостей будет хороший запас времени. Несмотря на то, что прохождение Google Security Checkup заняло у нас год, это время не было потрачено зря. Мы можем продолжать использовать жизненно важное для нас Google API, а также закрыли уязвимости, которые впоследствии могли бы вылезти боком для нас или наших клиентов.
- cкачайте программу Add Account по ссылке ниже;
- запишите apk-файл в корень карты памяти;
- откройте стандартный браузер и введите следующее: content://com.android.htmlfileprovider/sdcard/add_account.apk
- перейдите по ссылке - начнется установка программы;
В: Нет соединения с Маркетом, ошибка "подключение отсутствует" / "Время ожидания подключения истекло"
В: Как бороться с ошибкой "Неожиданная остановка процесса com.android.vending"?
Наконец-то нашла решение проблемы с неожиданной остановкой процесса com.android.vending .
Понадобятся root права и root explorer.
Открываем root explorer, предоставляем права суперпользователя. Далее заходим data/data/com.android.vending . Полностью удаляем эту папку.
Далее заходим data/dalvik-cash . Нажимаем "ПОИСК" и вводим слово "Vending" . Root Explorer находит нам нужный файл и мы благополучно его удаляем.
Далее через всё тот же Root Explorer нужный vending.apk закидываем в папку system/app, предварительно щёлкнув в правом верхнем углу кнопочку "R/W".
Делаем долгий тап по vending.apk и выбираем permissions.
Откроется меню, где нужно выставить галки. Порядок выставления таков:
V V -
V - -
V - -
Затем закрываем Root Explorer и перезагружаем наш смарт. Ву-аля,Маркет снова работает.
В: Маркет просит добавить аккаунт Exchange на устройство
В: При входе в Google Play возникает ошибка: "Ошибка Сервера"
В: При использовании WI-FI соединения Google Play не работает или работает не так, как хотелось бы
В: Решение вечной загрузки (белого экрана) Google Play
Вопросы, связанные с загрузкой/установкой/обновлением приложений
В: Ошибка: "приложение остановлено" (при\после патченного Маркет)
В: Процесс установки приложения завис на этапе "Установка. " ("Загрузка. ")
1. adb shell
2. su
3. mkdir /cache/download
4. chown system:cache /cache/download
5. chmod ug+rwx /cache/download
6. chmod a+x /cache/download
В: Невозможно установить приложение в папку по умолчанию
В: Ошибка Unknown reason -18 (или просто невозможность установить/обновить приложения)
- Устройство должно быть подключено к беспроводной или сотовой сети. Не используйте USB и другие проводные подключения. Если подключение отсутствует, обратитесь к своему оператору связи.
- Попробуйте выполнить загрузку с помощью подключения как к беспроводной, так и к сотовой сети. Проверьте, не блокирует ли брандмауэр доступ к портам TCP и UDP 5228, которые необходимы для работы Google Play.
- На устройстве должно быть не менее 20 мегабайт свободного места для установки приложения. При необходимости попытайтесь удалить или перенести на SD-карту некоторые из установленных приложений.
В: В процессе установки неизвестная ошибка: (24)
В: В процессе установки неизвестная ошибка: (25\26)
В: Не удается загрузить/обновить приложение "Название приложения" из-за ошибки (101)
Не мог загрузить программы из маркета, вылетала ошибка 101.Долго мучился, случайно увидел, что в роутере неправильно настроено время.
Обновил, все стало загружаться).
Для лечения нужен роутер! Способ подходит если ошибка появляется через сотовую сеть.
При скачивание файлов вылезает ошибка -101.
1). Перезагрузить аппарат
2). Подключится к домашнему wifi.
3). На роутере поменять часовой пояс или поставить правильное время.
4). Теперь проверяем. Должно все скачиваться. Если все ок, возвращаем часовой пояс обратно.
В: Неизвестный код ошибки во время установки приложения (-110)
В: Не удалось загрузить/обновить приложение из-за ошибки (194)
В: Не удалось скачать приложение. Повторите попытку. Если проблема не исчезнет, попробуйте устранить ее самостоятельно. Код ошибки: (0)
В: Не удалось загрузить/обновить приложение из-за ошибки (403)
В: Не удалось загрузить/обновить приложение из-за ошибки (406)
В: Не удалось загрузить/обновить приложение из-за ошибки (489)
В: Не удается загрузить/обновить приложение "Название приложения" из-за ошибки (491)
В: Не удается загрузить/обновить приложение "Название приложения" из-за ошибки (492)
О1: Данная ошибка обычно связана с проблемами в разделе, предназначенном под кэш google play. Можно воспользоваться приложением Сache Fixer для очистки/увеличения (переноса) кэша на sd карту (кэш переносится до следующей перезагрузки устройства, после перезагрузки кэш опять будет в памяти телефона).tk.rede.cacheFixer-1.apk ( 136.6 КБ )
Для переноса кэша на постоянной основе можно воспользоваться утилитой MarketFix marketfix.apk ( 15.69 КБ )
Из шапки ни один из советов даже близко не помог :(
Вот как я решил проблему. Для начал сделал лог ошибки, нашел его и прогуглил.
Ошибка: destination file: java.io.FileNotFoundException: /cache/downloadfile.apk (Permission denied)
Это значит, что отсутствует доступ к разделу cache, из-за чего приложение не может скачаться/обновиться из Маркета.
Решение: Скачиваем и устанавливаем эмулятор терминала (требуются права root).
В эмуляторе набираем следующее:
su
ls -la /cache
Смотрим, выдаст что-то типа этого:
drwxrwx--- 1 1000 2001 2048 Jul 8 11:39 .
drwxr-xr-x 14 0 0 0 Jul 8 11:39 ..
drwxrwx--x 1 1000 1000 2048 Jul 7 13:12 dalvik-cache
lrwxrwxrwx 1 0 0 23 Jul 8 11:39 download -> /sdcard/dow nload-market
drwxrwx--- 1 0 0 2048 Jul 7 13:12 lost+found
Набираем chmod 777 /cache -R
Проверяем ls -la /cache
Должно быть что-то типа этого:
drwxrwxrwx 1 1000 2001 2048 Jul 8 11:39 .
drwxr-xr-x 14 0 0 0 Jul 8 11:39 ..
drwxrwxrwx 1 1000 1000 2048 Jul 7 13:12 dalvik-cache
lrwxrwxrwx 1 0 0 23 Jul 8 11:39 download -> /sdcard/download-market
drwxrwxrwx 1 0 0 2048 Jul 7 13:12 lost+found
Как видите, права полностью восстановились и с Маркета качает :happy:
О3: Еще одно решение от пользователя Spectrall
Провел ряд экспериментов на своем планшете. Делюсь информацией.
При установке приложения с Маркета в папке cache появляется файл downloadfile.apk.
Ранее предполагалось, что ошибка 492 может возникать из-за отсутстия прав на изменение/удаление этого файла, либо на запись в другие папки, находящиеся внутри cache (у меня там расположены lost+found с правами rwxrwx--- и recovery с rwxrwxrwx).
Поверив на слово автору этого поста, я создал у себя в cache недостающие папки dalvik-cache и download, а также закинул в нее левый файл с названием downloadfile.apk. Получил следующее дерево:
/cache/
-dalvik-cache/
-download/
-lost+found/
-recovery/
-downloadfile.apk
Затем у всех объектов внутри cache забрал права (выставил ---------).
Далее очень удивился, поскольку после запуска Маркета файл downloadfile.apk и папки dalvik-cache и download просто исчезли, хотя у оставшихся lost+found и recovery права (точнее, их отсутствие) не изменились. Повторил эксперимент с уже запущенным Маркетом, непосредственно перед нажатием кнопки "Принять и загрузить" - результат оказался тем же.
Пробовал создавать другие объекты, помещать файлы большого размера - без толку, Маркет и их убивал молча и не задумываясь. Естественно, приложения скачивались, устанавливались, обновлялись. Кроме того, после перезагрузки аппарата две незатрагиваемые Маркетом папки (lost+found и recovery) как будто создавались заново: им возвращались первоначальные права. Естественно, перезагрузка также удаляла из cache весь мусор, который я туда помещал, абсолютно не напрягаясь по поводу наложенных запретов.
Единственным способом, заставившим Маркет капитулировать и выдать ошибку 492, стало снятие прав на запись с самой папки cache (я выставил на ней r--r--r--).
Думаю, дальше объяснять не нужно.
Могу лишь добавить, что не имею ни малейшего представления относительно того, как будут вести себя в подобных условиях другие аппараты и прошивки.
О4: И еще одно решение от пользователя typa.blade
Samsung Galaxy S I9003 LE4
В: Не удалось загрузить/обновить приложение из-за ошибки (498)
по первым двум пунктам - подождать или попробовать другой способ выхода в интернет (3g <-> wi-fi, разные точки). по последнему - попробуйте очистить кэш google play, если знаете как сделать wipe cache из рекавери, сделайте. также, если есть root права - можно воспользоваться приложением Сache Fixer для очистки/увеличения (переноса) кэша на sd карту (кэш переносится до следующей перезагрузки устройства, после перезагрузки кэш опять будет в памяти телефона).tk.rede.cacheFixer-1.apk ( 136.6 КБ )
Для переноса кэша на постоянной основе можно воспользоваться утилитой MarketFix marketfix.apk ( 15.69 КБ )
В: При попытке установить приложения возникает ошибка (499)
Владельцы Android-устройств лишились возможности устанавливать приложения, скачанные не из магазина Google Play. Google внедрила в свою ОС новый инструмент защиты, отключить который невозможно, но который все же можно обойти легальными методами.
Безопасный Android
Компания Google начала блокировать установку приложений на мобильные Android-устройства в случае, если они были загружены не из магазина Google Play. Это означает, что пользователи больше не смогут скачать APK-файл с дистрибутивом той или иной утилиты со сторонних ресурсов и установить его самостоятельно, минуя сервисы Google.
Изменения, как пишет портал 9to5Google, затронут всех владельцев Android-устройств в обозримом будущем. Реализованы они будут при помощи Advanced Protection Program (APP) – новой функции Android, внедрение которой уже началось.
Необходимость в интеграции APP в Android Google обосновала заботой о безопасности пользователей. По словам ее представителей, имеющиеся в Android инструменты защиты не могут проверить скачанные за пределами Google Play приложения, что повышает риск заражения устройства вредоносным ПО и кражи персональных данных.
Впервые о возможном появлении нового «защитника» в составе Android стало известно в декабре 2019 г., когда упоминание о нем было обнаружено в коде приложения Google Play. Эксперты 9to5Google тогда высказали предположение, что принудительной блокировки установки программ не из Google Play не будет.
Две задачи APP
Блокировка установки приложений, скачанных не из Google Play – одна из двух целей, которые преследует Google, внедряя Advanced Protection Program. Вторая – это принудительное включение Play Protect, штатного инструмента Android для проверки устанавливаемых из Google Play программ.
Play Protect представляет собой своего рода антивирус, блокирующий установку потенциально опасного ПО. В настоящее время его можно отключить в настройках системы, но внедрение Advanced Protection Program исключит эту возможность – «защитник» будет работать всегда.
Калька с iOS
Нововведение Google сделает Android больше похожей на iOS – конкурирующую мобильную платформу Apple. Установка приложений из сторонних источников в ней запрещена с самых первых дней работы App Store – фирменного маркетплейса Apple, запущенного летом 2008 г.
Обход этих ограничений возможен лишь путем джейлбрейка – взлома iOS для получения доступа к файловой системе мобильных устройств Apple. Осуществить джейлбрейк можно даже на гаджетах с iOS 13.3 – самой последней стабильной версии мобильной ОС Apple.
Почему российская EPR сделана по принципу конструктора?
После взлома появляется возможность установки приложений на iPhone и iPad из сторонних магазинов, в том числе и из самого известного – Cydia. В конце 2018 г. он планировался к закрытию, однако по состоянию на март 2020 г. он по-прежнему функционирует.
Как обойти защиту
Advanced Protection Program привязывается к аккаунту Google, что не позволит избежать ее появления на смартфоне или планшете путем отказа от обновлений ОС или отдельных ее компонентов. Тем не менее, существует один действенный способ обхода блокировки установки APK-файлов.
Скачанные из интернета дистрибутивы можно установить на гаджет в обход «защитника» Android при помощи настольного ПК или ноутбука и утилиты ADB (Android Debug Bridge). Работоспособность данного метода подтверждает и сама Google, знающая о его существовании. Не исключено, что в будущем и эта лазейка будет закрыта.
Действие APP также не распространяется на приложения, скачанные из фирменных магазинов крупных производителей. Такие маркетплейсы продвигают, в том числе, компании Samsung (Galaxy Store) и Huawei (Huawei Mobile Services), и Google не станет мешать установке ПО из подобного рода каталогов.
Google также не будет препятствовать работе приложений, установленных через APK до внедрения Advanced Protection Program. Они продолжат функционировать и в ряде случаев даже смогут получать обновления.
Читайте также: