Update android version перевод

Apply update from ADB: перевод на русский язык и что это такое на Android?

Многие пункты рекавери меню смартфонов Android вызывают у пользователей недоумение. Например, что значит пункт и как переводится Apply update from ADB? Переводится словосочетание примерно как «обновление с помощью ADB». Все еще непонятно? Давайте разбираться.

Главным словом здесь являет ADB или Android Debug Bridge, то есть отладочный мост Android — он используется для того, чтобы пользователь мог получить доступ к системе своего смартфона, подключив тот к компьютеру или ноутбуку посредством кабеля USB. После подключения управление устройством осуществляется командной строкой. Для чего это нужно? Вот лишь некоторые причины:

• Разблокировка смартфона.

• Перепрошивка смартфона или его обновление.

• Недоступность версии Android в определенном регионе.

• Запуск смартфона с проблемами.

В некоторых случаях использование отладочного моста настолько необходимо, что без него нельзя перепрошить устройство, которое, скажем, превратилось в «кирпич». А вот как выглядит указанный пункт в меню рекавери:

Пример для другого рекавери меню — TWRP:

Как воспользоваться ADB?

Заряжаете смартфон минимум до 50-60% (лучше зарядить до 100%).

Скачиваете с официального сайта Android пак с инструментами (SDK Platform Tools), распаковываете в корень диска C и переименовываете в adb для удобства.

Переводите смартфон в режим рекавери и выбираете пункт Apply update from ADB.

Далее подключаетесь с помощью командной строки к смартфону — запускаете от имени администратора.

Подключаетесь к устройству с помощью команды CD C:/adb.

Используете нужные вам команды.

Процесс подключения показан в общих чертах. Могут понадобиться драйвера для установки соединения между устройствами.

Друзья! Если наш сайт помог вам или просто понравился, вы можете помочь нам развиваться и двигаться дальше. Для этого можно:

• Оставить комментарий к статье.

Источник

Обновляемся на новую версию API Android по наставлению Google

Скоро выходит Android 12, но в этом августе уже с 11-й версии разработчикам придётся использовать новые стандарты доступа приложений к внешним файлам. Если раньше можно было просто поставить флаг, что ваше приложение не поддерживает нововведения, то скоро они станут обязательными для всех. Главный фокус — повышение безопасности.

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

Что происходит

Если вы уже знакомы с теорией, то этот раздел можно пропустить — тут я хочу поверхностно сравнить подходы к предмету в разных версиях операционной системы.

В Android есть внутреннее Internal Storage (IS) и внешнее хранилище External Storage (ES). Исторически это были встроенная память в телефоне и внешняя SD-карта, поэтому ES был больше, но медленнее и дешевле. Отсюда и разделение — настройки и критически важное записывали в IS, а в ES хранили данные и большие файлы, например, медиа. Потом ES тоже стал встраиваться в телефон, но разделение, по крайней мере логическое, осталось.

У приложения всегда есть доступ к IS, и там оно может делать что угодно. Но эта папка только для конкретного приложения и она ограничена в памяти. К ES нужно было получать доступ и, кроме манипуляции со своими данными, можно было получить доступ к данным других приложений и производить с ними любые действия (редактировать, удалять или украсть).

Но после разделения на внутреннее и внешнее хранилища все равно оставались проблемы. Многие приложения могли хранить чувствительную информацию не только в IS, но и в ES — то есть ответственность лежала целиком на разработчиках и на том, кто хочет завладеть файлами.

В Android решили всё это переделать ещё в 10-й версии, а в 11-й это стало обязательным.

Чтобы минимизировать риски для пользователя в Google решили внедрить Scoped Storage (SS) в ES. Возможность проникнуть в папки других приложений убрали, а доступ есть только к своим данным — теперь это сугубо личная папка. А IS с 10-й версии ещё и зашифрована по умолчанию.

В Android 11 Google зафорсировала использование SS — когда таргет-версия SDK повышается до 30-й версии API, то нужно использовать SS, иначе будут ошибки, связанные с доступом к файлам. Фишка Android в том, что можно заявить совместимость с определённой версией ОС. Те, кто не переходили на 11, просто говорили, что пока не совместимы с этой версий, но теперь нужно начать поддерживать нововведения всем. С осени не получится заливать апдейты, если не поддерживаешь Android 11, а с августа нельзя будет заливать новые приложения.

Если SS не поддерживается (для девайсов ниже 10-й версии), то для доступа к данным других приложений требуется получить доступ к чтению и записи в память. Иначе придётся получать доступ к файлам через Media Content, Storage Access Framework или новый, появившийся в 11-м Android, фреймворк Datasets в зависимости от типа данных. Здесь тоже придётся получать разрешение доступа к файлу, но по более интересной схеме. Когда расшариваемый файл создаёшь сам, то доступ к нему не нужен. Но если переустановить приложение — доступ к нему опять потребуется. К каждому файлу система привязывает приложение, поэтому когда запрашиваешь доступ, его может не оказаться. Особо беспокоиться не нужно, это сложно отследить, поэтому лучше просто сразу запрашивать пермишен.

Media Content, SAF и Datasets относятся к Shared Storage (ShS). При удалении приложения расшаренные данные не удаляются. Это полезно, если не хочется потерять нужный контент.

Хотя даже при наличии SS можно дать доступ к своим файлам по определённой технологии — через FileProvider можно указать возможность получения доступа к своим файлам из другого приложения. Это нормально, потому что файлы расшаривает сам разработчик.

Также добавилась фича — если приложение не использовалось несколько месяцев, то снимаются все пермишены и доступы к системным элементам. По best practice разрешение запрашивается по необходимости (то есть непосредственно перед использованием того, на что спрашиваем разрешение), поэтому мы просто перед выполнением какого-либо действия проверяем, есть ли у нас пермишены. Если нет, то запрашиваем.

В то же время перекрыли доступы к приложениям внутри девайса. Если раньше можно было отследить, что установлены определённые приложения и отправлять к ним соответствующие интенты, то сейчас мы должны прямо в манифесте прописать, что работаем именно с этими приложениями, и только после этого получить доступ.

В качестве примера можем взять шаринг — мы шарим множество приложений, и их всех нужно указывать в манифесте, иначе они не обнаружатся. Начнём перебирать пакет установленных приложений — будет информация, что не указанного в манифесте приложения нет и при шаринге всё отвалится.

Перейдём к практике.

Переход на новую версию

Основная функциональность по работе с файлами в приложении iFunny представлена в виде сохранения мемов в память и расшаривания их между приложениями. Это было первое, что требовалось починить.

Для этого выделили в общий интерфейс работу с файлами, реализация которого зависела от версии API.

FilesManipulator представляет собой интерфейс, который знает, как работать с файлами и предоставляет разработчику API для записи информации в файл. Copier — это интерфейс, который разработчик должен реализовать, и в который передаётся поток вывода. Грубо говоря, мы не заботимся о том, как создаются файлы, мы работаем только с потоком вывода. Под капотом до 10-й версии Android в FilesManipulator происходит работа с File API, после 10-й (и включая её) — MediaStore API.

Рассмотрим на примере сохранения картинки.

Так как операция сохранения медиафайлов достаточно длительная, то целесообразно использовать MediaStore.Images.Media.IS_PENDING , которая при установлении значения 0 не дает видеть файл приложениям, отличного от текущего.

По сути, вся работа с файлами реализована через эти классы. Шаринг в другие приложения автоматически сохраняют медиа в память устройства и последующая работа с URI уже происходит по новому пути. Но есть такие SDK, которые ещё не успели перестроиться под новые реалии и до сих пор используют File API для проверки медиа. В этом случае используем кеш из External Storage и при необходимости провайдим доступ к файлу через FileProvider API.

Помимо ограничений с памятью в приложениях, таргетированных на 30-ю версию API, появилось ограничение на видимость приложения. Так как iFunny использует шаринг во множество приложений, то данная функциональность была сломана полностью. К счастью, достаточно добавить в манифест query, открывающую область видимости к приложению, и можно будет также полноценно использовать SDK.

Для неявных интентов тоже приходится добавлять код в манифест, чтобы задекларировать то, с чем будет работать приложение. В качестве примера выложу часть кода, добавленного в манифест.

После проверок запуска UI-тестов на девайсах с версиями API 29-30 было выявлено, что они также перестали корректно отрабатываться.

Первоначально в LogCat обнаружил, что приложение не может приконнектиться к процессу Orchestrator и выдает ошибку java.lang.RuntimeException: Cannot connect to androidx.test.orchestrator.OrchestratorService.

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

Тест удачно запустился, но возникла другая ошибка — Allure не может сохранить отчёт в память устройства, падает с ошибкой.

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

Так как нам нужно использовать этот пермишен только для тестов, то нам условия подходят. Поэтому я быстренько написал свой ShellCommandExecutor, который выполняет команду adb shell appops set —uid PACKAGE_NAME MANAGE_EXTERNAL_STORAGE allow на создании раннера тестов.

На Android 11 тесты удачно запустились и стали проходить без ошибок.

После попытки запуска на 10-й версии Android обнаружил, что отчет Allure также перестал сохраняться в память девайса. Посмотрев issue Allure, обнаружил, что проблема известная, как и с 11-й версией. Достаточно выполнить команду adb shell appops set —uid PACKAGE_NAME LEGACY_STORAGE allow . Сказано, сделано.

Запустил тесты — всё еще не происходит сохранения в память отчёта. Тогда я обнаружил, что в манифесте WRITE_EXTERNAL_STORAGE ограничен верхней планкой до 28 версии API, то есть запрашивая работу памятью мы не предоставили все разрешения. После изменения верхней планки (конечно, для варианта debug) и запроса пермишена на запись тесты удачно запустились и отчёт Allure сохранился в память устройства.

Добавлены следующие определения пермишенов для debug-сборки.

После всех вышеописанных манипуляций с приложением, можно спокойно устанавливать targetSdkVersion 30, загружать в Google Play и не беспокоиться про дедлайн, после которого загружать приложения версией ниже станет невозможно.

Источник

Обновление прошивки на Android-автомагнитоле

Внимание! Все дальнейшие действия вы выполняете на свой страх и риск!

Этап 1: Подготовка

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

Первым делом следует определить конкретную модель вашей автомагнитолы. Самое простое решение этой задачи заключается в использовании настроек девайса – откройте его главное меню и тапните по соответствующей иконке.

Пролистайте параметры до пункта «Информация» и перейдите к нему.

Далее поищите опцию «MCU» – там будут нужные нам сведения.

Альтернативный вариант – открыть «Android настройки».

Далее воспользуйтесь пунктом «О телефоне».

В строке «Система» будут размещены нужные сведения.

После определения модельного ряда нужно найти свежие файлы обновлений. Здесь есть два пути – первый заключается в получении апдейтов с официального сайта устройства. Если таковой отсутствует, придётся воспользоваться сторонними источниками.

После получения архива с файлами выберите флешку, требования к ней следующие:

• объём – не менее 8 Гб;
• файловая система – FAT32;
• тип коннектора – желательно USB 2.0, который медленнее, но более надёжный.

Отформатируйте накопитель, затем распакуйте архив с файлами прошивки в его корень.
В некоторых моделях магнитолы обновление софта происходит с удалением всех пользовательских данных, поэтому озаботьтесь созданием резервной копии, если в этом есть необходимость.

Подробнее: Как сделать резервную копию Android-устройства перед прошивкой
Нередко они также сбрасывают конфигурацию в процессе, поэтому не лишним будет сделать и бэкап настроек. Откройте параметры устройства и поищите пункт «Настройки автомобиля». Если он отсутствует, переходите к прошивке, но если таковой есть, тапните по нему.

Для доступа к ним понадобится ввести пароль. Эту информацию можно найти в документации к устройству либо попробуйте ввести универсальную комбинацию 668811 .

Среди настроек найдите пункт «Информация о конфигурации» и перейдите к нему.

Откроется всплывающее окно с параметрами – сфотографируйте их или запишите.

Этап 2: Прошивка

Теперь переходим непосредственно к прошивке магнитолы.

1. Вставьте флешку в USB-порт.
2. Дальше есть два варианта. Первый – магнитола самостоятельно определит наличие файлов прошивки и предложить произвести обновление, нажмите «Start», затем переходите к шагу 5.

Другой вариант заключается в установке обновлений вручную. Для этого откройте путь «Настройки» – «Система» – «Обновления», или же «Система» – «Расширенные настройки» – «Обновление системы».

Будет предложено выбрать источник, укажите «USB». Дополнительные опции в этом случае лучше не трогать.

Начнётся операция обновления системного ПО – подождите, пока она завершится. После появления сообщения об удачном обновлении магнитола начнёт перезагрузку, извлеките флешку.

Обновление основной прошивки завершено.

Решение некоторых проблем

Рассмотрим возможные сбои, которые возникают в процессе выполнения инструкции выше.

Магнитола не видит флешку

Если устройство не распознаёт USB-накопитель, выполните следующее:

1. Проверьте работоспособность носителя – возможно, он вышел из строя. При обнаружении неполадок просто замените его.
2. Подключите носитель к компьютеру и проверьте файловую систему – возможно, вместо FAT32 вы использовали что-то другое. В такой ситуации просто отформатируйте флешку в нужный вариант.

Флешка видна, но магнитола не видит прошивку

Если гаджет не может распознать файлы обновлений, причин у этого две – вы загрузили данные для другой модели или же распаковали их не полностью либо не в корень флешки. Решить проблему можно так:

1. Отсоедините USB-носитель от магнитолы и подсоедините его к ПК либо ноутбуку. Проверьте местоположение файлов, их количество и размеры.
2. Также, если присутствует документ сверки хэш-сумм в формате MD5, сверьте данные с его помощью.

Подробнее: Чем открыть MD5

Имеет значение и источник файлов – возможно, недобросовестные пользователи выложили неподходящие для вашей модели.

Воспользуйтесь другим компьютером для выполнения подготовительного этапа, если ни один из вышеприведённых шагов не помог.

Проблемы в процессе прошивки Android-автомагнитол возникают редко.

Помимо этой статьи, на сайте еще 12473 инструкций.
Добавьте сайт Lumpics.ru в закладки (CTRL+D) и мы точно еще пригодимся вам.

Отблагодарите автора, поделитесь статьей в социальных сетях.

Источник