Обновление приложения android studio
Создание APK или подписанного пакета из Android Studio - это необходимый шаг для настройки приложения в Google Play Store, так как пакет приложений Google Android и пакет Google Play APK - это пакеты, которые необходимо создать, чтобы загрузить пакет приложений в Play Store и иметь приложение опубликовано в GooglePlayStore.
Ниже приведен пример продолжения нашего примера создания лучшего бюджетного приложения для Android с использованием бесплатного существующего кода из партнерской программы TravelPayouts.
Создать подписанный пакет или APK из Android Studio
Создать подписанный пакет или APK из AndroidStudio довольно просто, если вы можете использовать новый ключ загрузки и не забыли пароль своего ключа загрузки - иначе он не будет работать.
Чтобы создать APK из Android-студии, начните с открытия меню «Создать подписанный пакет» или «APK».
Затем выберите, хотите ли вы создать подписанный пакет приложений Google Android или Google Play APK.
Для того чтобы сгенерировать подписанный пакет, необходимо будет предоставить ключ. Если у вас есть существующий ключ, используйте кнопку «Выбрать существующий».
Если нет, начните создавать новый ключ.
Создать новый ключ загрузки Play Store
Чтобы создать новый ключ загрузки, введите всю необходимую информацию в форме: путь к хранилищу ключей, соответствующие пароли, псевдоним, соответствующий пароль ключа, срок действия в годах, имя и фамилия, организационная единица, организация, город или населенный пункт, штат или провинция и код страны ISO.
Затем сгенерируйте ключ, который будет сохранен на вашем компьютере.
Теперь можно создать свой пакет приложений Google Android, и вы можете загрузить пакет приложений в Play Store - если только вы не столкнулись с проблемой, такой как использование нового ключа для уже существующего приложения.
Сбросить ключ загрузки Google Play
Чтобы сбросить ключ загрузки в Google Play, вам нужно связаться со службой поддержки Google Play и попросить их сбросить ключ загрузки.
Через некоторое время служба поддержки ответит на запрос о создании нового ключа, как описано выше, и о новом сертификате ключа в формате PEM.
Установите KeyStore Explorer, чтобы получить сертификат PEM.
Загрузите и установите его, чтобы получить этот сертификат PEM.
После этого запустите приложение из меню «Пуск» Windows.
Установите Java для KeyStore Explorer
Может потребоваться установить последнюю версию Java, прежде чем можно будет запустить программу KeyStore Explorer и получить сертификат PEM.
Получите сертификат ключа PEM от ключа загрузки
После установки Java-программы вы, наконец, сможете установить программу KeyStore Explorer.
Выберите для начала открыть существующее хранилище ключей.
Затем найдите на своем компьютере ключ в формате .jks, который был создан ранее с помощью AndroidStudio.
Пароль будет запрошен, чтобы открыть этот ключ, и вы должны будете предоставить его, чтобы ввести его детали.
После того, как ключ был открыт, дважды щелкните по нему, чтобы использовать его для загрузки пакета приложений в Play Store, дважды щелкнув по нему.
Все детали будут отображены, и вы сможете нажать на кнопку PEM, чтобы получить доступ к знаменитому сертификату PEM.
Когда отобразится сертификат PEM, просто нажмите «Экспорт», чтобы сохранить его на своем компьютере, и отправьте этот файл в службу поддержки Google Play, чтобы сбросить ключ загрузки.
Через некоторое время они подтвердят, что ключ был сброшен, и что вы можете использовать новый ключ загрузки для генерации подписанных пакетов или APK для загрузки пакета приложений в Play Store - все еще потребуется несколько дней, чтобы новые ключи стали действительный.
Вся операция по сбросу ключа загрузки в Google Play занимает около недели, после чего можно будет снова загрузить комплект приложений Google Android в новом выпуске приложения.
Распространенные проблемы обновления релиза приложения
Обновление моего приложения для Android не развертывается: если новый выпуск не предлагается для загрузки пользователям, которые уже установили приложение, а выпуск приложения на консоли Google Play отображается как опубликованный со всеми живыми обновлениями, это может быть связано с тем, что код версии и название версии не были обновлены, что не позволяет пользователям телефонов идентифицировать обновление как новую версию.В Play Store установлена новая версия приложения, но не отображается обновление
Обновление приложений и поддержка актуальной версии у пользователей это очень важный момент в жизненном цикле каждого приложения. От части это зависит от того, что Android постоянно изменяется: какие-то методы и классы добавляются, какие-то становятся устаревшими, и примерно раз в год с выходом новой версии следует обновлять targetSdkVersion и переписывать код, если это требуется. Кроме того, постоянно обновляются сторонние библиотеки, которые нужно также обновить у себя в приложении, добавляются новые функции и особенности в само приложение. И про багфиксы не стоит забывать, нужно постоянно отслеживать баги в приложениях и оперативно исправлять, потому что недовольный пользователь скорее всего испортит статистику приложению негативным отзывом.
Всё это вынуждает постоянно поддерживать приложение. Отсюда вытекает следующий момент: как установить актуальную версию приложения максимальному числу пользователей.
Этот вопрос от части решает сам Google Play. Он присылает уведомления пользователю о том, что доступна новая версия приложения, предлагает включить автоматическое обновление приложений, что обеспечивает самую свежую версию приложения на устройстве. Однако не все пользователи использую эту возможность, многие обновляют от случая к случаю, игнорируют уведомления.
В этом случае мы можем взять дело в свои руки и встроить механизм обновления в само приложения.
В прошлом году Google выпустили механизм In-App Updates с целью ещё больше ускорить обновление приложений у пользователей. In-App Updates позволяет показывать пользователю при входе в приложение диалог, где ему будет предложено обновить приложение до последней версии. Этот функционал работает, начиная с версии Android 5.0 (API 21). Кроме того, приложение должно быть опубликовано в Google Play.
In-App Updates поддерживает два способа обновления приложения:
- Flexible. Если пользователь согласится на обновление приложения, загрузка начнётся в фоновом режиме, при этом пользователь сможет продолжить пользоваться приложением. Как только загрузка завершится, в приложение (если оно активно) придёт результат загрузки, после чего мы можем либо предложить перезапустить приложение, либо дождаться, когда пользователь из него выйдет. Если же на момент окончания загрузки приложение находилось в фоновом режиме, то установка новой версии начнётся сразу же. Такой подход удобен в большинстве случаев, поскольку позволяет обновить приложение, не мешая пользователю.
- Immediate. Пользователь не сможет работать в приложении до тех пор, пока не обновится до новой версии. Когда он согласится на обновление, на этом же экране начнётся процесс загрузки и установки, после чего приложение перезапустится. Такой подход нужен в случае, если вышло критическое обновление приложения, либо если старая версия приложения более не может работать корректно. В остальных случаях лучше всего использовать первый вариант.
Перед началом работы нужно добавить библиотеку Play Core в приложение. Для этого в файле build.gradle модуля приложения добавим следующую зависимость:
Теперь создадим класс UpdateManager, в котором будем проводить работу, связанную с обновлением.
Перед тем, как показывать диалог, следует проверить наличие новой версии. Для этого воспользуемся классом AppUpdateManager для запроса к Google Play.
К экземпляру класса AppUpdateManager привязываем слушатель OnSuccessListener, который будет получать результат запроса. Если новая версия приложения доступна, отправляем интент, отображающий диалог для скачивания новой версии.
Если пользователь согласится на обновление, начнётся процесс загрузки в фоновом режиме. Обратите внимание, что с помощью метода startUpdateFlowForResult() мы можем узнать, какое действие выбрал пользователь. Для этого мы передаём в него константу UPDATE_REQUEST_CODE, результат с этим кодом придёт в метод onActivityResult() активности.
Здесь мы можем получить один из следующих результатов:
Поскольку мы используем Flexible метод обновления, нам нужно узнать, когда завершится загрузка новой версии. Для этого нам нужно добавить слушатель InstallStateUpdatedListener и привязать его к экземпляру AppUpdateManager после того, как начнётся загрузка. О том, что пользователь начал загрузку, мы узнаём, получим результат в методе onActivityResult() активности.
Сам же Snackbar выглядит очень просто, при нажатии на Restart мы вызываем completeUpdate(), как делали бы это, будучи в фоновом режиме.
Итоговый листинг класса UpdateManager выглядит следующий образом:
Итак, мы встроили In-App Updates в приложение, осталось только проверить его работу. Для этого отлично подойдёт такая особенность Google Play, как внутренний совместный доступ (Internal app-sharing). Он позволяет загружать APK или Android App Bundle на специальную страницу загрузки, к которым будут иметь доступ только тестировщики. Это позволяет быстро проверить приложение, при этом его не обязательно подписывать релизным ключом, можно делиться также и debug-версиями. Тестировщикам отправляется специальная ссылка на скачивание, которая перенаправляет их в Google Play, где им будет предложено установить данную версию приложения.
Теперь мы можем перейти на страницу загрузки для внутреннего совместного доступа. Сюда мы может публиковать различные APK для тестирования. Соберём два APK нашего приложения с разными кодами версий (например, 23 и 24) и загрузим их на эту страницу. При загрузке мы также можем задать название данной версии, чтобы было проще их различать.
После того, как APK будут загружены, они отобразятся в списке.
С этого момента мы готовы тестировать эти версии. Зайдём на устройство, с которого будем запускать приложение, и на нём перейдём по ссылке от версии 1.23. Откроется специальная страница, которая предложит перейти в Google Play для установки.
После перехода в Google Play нам будет предложено установить эту версию приложения.
Как только установка завершится, открываем приложение. В нашем приложении под списком меню указывается текущий код и версия приложения, поэтому будем ориентироваться на неё, что обновление прошло успешно. Как видно, сейчас текущая версия 1.23.
Теперь закрываем приложение, снова открываем браузер и переходим уже по ссылке от версии 1.24. Нам аналогично будет предложено перейти в Google Play, только на этот раз мы можем не установить, а обновить или удалить приложение. Важно: не нужно обновлять приложение с этой страницы! Смотрим только, что она есть, и закрываем.
Снова заходим в наше приложение и, если всё сделано верно, отобразится диалог с предложением обновить версию.
Нажимаем Restart, и здесь в работу включаются сервисы Google Play, которые обновят приложение до новой версии.
После того, как установка завершится, приложение запустится автоматически. Скроллим список вниз и видим, что версия приложения теперь стала 1.24, значит обновление прошло успешно.
Таким образом, благодаря In-App Updates, пользователи смогут более быстро получать новые версии, чем при обновлении непосредственно через Google Play.
В 2019 году Google выпустила In-app Updates — возможность обновлять Android-приложения без перехода в Google Play. Однако до сих пор довольно мало приложений поддерживают этот способ обновления.
Когда я внедрял In-app Updates в приложение Профи для специалистов — без сложностей не обошлось. Пришлось покопаться в документации, статьях и даже пару раз переписать реализацию.
Чтобы меньше людей наступали на мои грабли, я сделал пошаговую инструкцию по интеграции In-app Updates в Android-приложение на React Native. Если следовать ей — сможете внедрить эту опцию за день.
Оговорка
Уже разработали несколько библиотек, инкапсулирующих реализацию In-app Updates. Например, эту или эту. Моя статья для тех, кто хочет добавить интеграцию самостоятельно.
Что будем делать
Разберёмся, как тестировать эту фичу. Ведь она требует взаимодействия с Google Play.
Подготовка к тестированию
Нам придётся неоднократно тестировать код. Поэтому сперва разберёмся, как это делать.
Для проверки In-app обновлений Google разработала специальную тестовую среду, в которую можно загрузить apk-файл или bundle приложения и затем установить на устройство. Через неё же будем имитировать появление обновления.
Готовим устройство.
Устанавливать приложения из тестовой среды можно как на реальные устройства, так и на эмуляторы. В любом случае нужно настроить Google Play (названия кнопок на вашем устройстве могут отличаться, но суть одна):
Заходим в Google Play, кликаем на своё фото, выбираем «Настройки».
В разделе «Сведения» кликаем много раз подряд на «Версию Google Play», пока не станем разработчиком.
Включаем тогл «Внутренний доступ к приложениям» в разделе «Личные» или «Общее».
Собираем apk- или aab-файл приложения.
Для тестирования подойдёт обычная debug-сборка, без каких-либо подписей и js-бандлов. В Android Studio это Build -> Build Bundle(s) / APK(s) -> <предпочитаемый тип сборки>. Такое приложение после установки будет при запуске подключаться к js-бандлеру и загружать js-код.
Ещё к нему можно подключить дебаггер Android Studio, чтобы отлаживать нативный код. Для этого нужно нажать на «жучка со стрелочкой» в панели инструментов Android Studio (Attach debugger to Android Process) и выбрать запущенное приложение.
Уточню, что устройство должно быть подключено к компьютеру, а тип подключения должен разрешать обмен данными. Чтобы избежать проблем с подключением, советую пользоваться эмулятором.
Загружаем полученный файл в Internal App Sharing и указываем название версии.
Советую добавлять к названию инкрементируемое число, чтобы не путаться. Тестирование вряд ли ограничится двумя-тремя сборками.
Копируем ссылку на приложение, открываем на устройстве и устанавливаем.
Готовим обновление.
Чтобы имитировать обновление, нужно повторить шаги 2–4 со следующими нюансами:
номер сборки (versionCode) должен быть больше номера установленной сборки;
желательно добавить изменения, которые заметны сразу при запуске. Так проще понять, что приложение обновилось;
устанавливать сборку не нужно. Надо перейти по ссылке и попасть на экран с кнопкой «Обновить» или Update.
Если не использовать Internal App Sharing — обновление будет недоступно.
Поддержка immediate-обновлений
Immediate-обновления почти полностью реализует Google. Нужно только запросить проверку на наличие новой версии. Если она есть, Google покажет пользователю полноэкранный баннер, загрузит, установит обновление и перезапустит приложение.
Создадим нативный модуль с методом проверки наличия обновления.
(Здесь и далее код на Kotlin и JavaScript)
Проверяем наличие новой версии. Если она есть, то запускаем обновление. APP_UPDATE_REQUEST_CODE — это числовая константа, определяющая наш запрос. С её помощью мы идентифицируем сигнал, если в процессе обновления произойдёт ошибка.
Чтобы иметь возможность переопределить метод onActivityResult в нативном модуле, нужно реализовать интерфейс ActivityEventListener .
Вызываем написанный метод из JS.
И вуаля — всё работает.
Поддержим установку обновления после сворачивания.
В процессе установки пользователь может свернуть приложение. Установка при этом должна продолжиться. А если пользователь вновь развернёт приложение, нужно убедиться, что процесс не остановился. Для этого добавим метод в нативном модуле:
Нужно вызывать его каждый раз, когда приложение становится активным. Для этого в React Native зарегистрируем слушателя изменений AppState :
Поддержка flexible-обновлений
Процесс flexible-обновлений выглядит так:
Google Play предлагает пользователю обновить приложение;
если пользователь соглашается, начинается фоновая загрузка обновления;
после загрузки мы предлагаем установить обновление с полноэкранной заставкой от Google Play и перезапуском приложения в конце;
eсли пользователь отказывается установить обновление в моменте, предлагаем ему повторно. Google рекомендует делать это на каждое разворачивание приложения, но тут воля ваша. Кстати, если приложение будет в фоне на момент завершения загрузки, то установка обновления произойдёт автоматически.
В отличие от immediate-обновлений, здесь придётся написать чуть больше кода.
Модифицируем написанные ранее методы, чтобы при их вызове можно было указать требуемый тип обновления.
Достаточно добавить аргумент для типа обновления в нативные методы checkForAppUpdate и resumeUpdate .
Объявим слушателя для наблюдения за процессом.
Слушатель должен реализовывать интерфейс InstallStateUpdatedListener .
Зарегистрируем его в методе checkForAppUpdate перед вызовом startUpdateFlowForResult :
Добавим трансляцию процесса обновления на уровень JS.
Мы хотим следить за ходом обновления на стороне React Native, чтобы иметь возможность показать пользователю прогресс загрузки или предложить установить обновление, когда оно скачается. Для этого будем транслировать статус из натива, используя EventEmitter .
Добавим в наш модуль:
И вызовем новый метод в слушателе:
bundle.toMap() — extension-функция, конвертирующая Bundle в WritableMap , который можно передавать в React Native
Добавим слушателя событий на стороне JS.
Использованные здесь константы дублируются из нативного кода.
Отлично! Теперь мы запрашиваем обновление из React Native и следим за его статусом. Но после успешной загрузки ничего не произойдёт. Нужно инициировать установку.
Предложим установить обновление.
Если пользователь согласится, нужно снова передать управление в натив и запустить установку обновления. Для этого добавляем и вызываем метод нативного модуля:
Обработаем отказ от установки.
Как я писал выше, в случае отказа от установки нужно напоминать пользователю об обновлении. Проще всего это делать при каждом переходе в приложение (будь то запуск или разворачивание). Тем более что в предыдущем разделе мы уже использовали этот триггер для проверки состояния immediate-обновления. Давайте добавим в нативный метод resumeUpdate проверку статуса обновления и, если оно остановится после загрузки, предложим обновиться:
Вот и всё. Обработка события на стороне React Native уже реализована, поэтому при получении статуса InstallStatus.DOWNLOADED пользователь вновь увидит предложение установить загруженное обновление.
Закругляюсь
Мы поддержали In-app обновления приложения двух видов — immediate, когда весь процесс под контролем Google, и flexible, в котором мы сами решаем, как показать пользователю прогресс и показывать ли вообще. Теперь можете решить, какой вид обновления лучше подходит вашему приложению. А может, вы захотите использовать оба варианта. Как бы то ни было, вся конфигурация управляется на стороне React Native, и писать нативный код больше не придётся.
Я рассказал про минимальную функциональность In-app обновлений. Ещё есть возможность управлять частотой показа баннера и приоритетами обновлений. Это легко поддержать на базе написанного нативного модуля. Просто эти опции выходят за рамки статьи.
Я намеренно не стал усложнять код в статье. Но рекомендую все методы взаимодействия с нативным модулем из React Native вынести в отдельный сервис, чтобы инкапсулировать всю логику в одном месте.
Несмотря на обилие кода, поддержка In-app обновлений реализуется легко. Надеюсь, мне удалось это показать в статье, и вы решитесь добавить такую опцию в ваше приложение. Лично мне она кажется удобной.
Как из одного приложения (A) запустить инсталляцию apk другого приложения (Б) (желательно полностью в авто режиме), а потом из приложения (A) запустить приложение (Б)?
Объясняю зачем: делается корпоративная программа, (работающая на нескольких планшетах), которая часто обновляется, и нужно написать агент, который должен в авто-режиме принимать apk по сети и обновлять приложение (Б).
Пишу на C++ Builder XE6, Андроид 7.
Ссылка на комментарий
22 ответа на этот вопрос
Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.
Похожий контент
В визуал студии в Xamarin есть такой класс -Java.Security.KeyStore Class, этот класс(как я понял) отвечает за подключение к хранилищу ключей андроида,короче говоря Android keystore system .
А вот как достучаться до этой функции в с++builder ?Я хочу сделать привязку приложения через Android keystore system ,а как это сделать в Rad студии не знаю
Нужна помощь!
Все перепробовал, не выходит каменный цветок.
На форме лежит скрытый компонент THUETrackBar.
Хочется реализовать следующий функционал на с++ (fmx): свайп вверх по любому месту экрана - делает компонент THUETrackBar видимым, и двигает его ползунок вверх, свайп вниз - соответственно вниз.
этот код не фурычит в процессе свайпа, только по завершении
Читайте также: