App release apk что это

Публикация приложения

После создания приложения, его тестирования и отладки мы можем приступить к его публикации. Суть публикации заключается в создании файла с расширением .apk, которое будет представлять приложение, и его последующее размещение в Google Play Market или на других внешних сайтах. По умолчанию в процессе отладки и создания приложения файл apk уже создается, и мы можем его найти в папке проекта по пути Название_проекта\app\build\outputs\apk. По умолчанию файл называется app-debug.apk и представляет debug-версию.

Но для полноценно публикации данного файла может оказаться недостаточно. И нам еще дополнительно надо произвести некоторую подготовку проекта к релизу. Для это следует указать в файле манифеста у элемента <manifest> установлены атрибуты android:versionCode и android:versionName . Также в файле манифеста элемент <application> не должен содержать атрибута android:debuggable

Кроме того, на этом этапе можно установить иконку для приложения, которая будет отображаться на рабочем экране гаджета, название приложения (атрибут android:label у элемента), а также можно задать лицензионное соглашение.

В файле манифеста также следует определить название пакета (атрибут package элемента <manifest> ), которое будет использоваться для приложения в дальнейшем. По умолчанию при разработке в Android Studio пакеты приложений начинаются с com.example. Не стоит оставлять данное название, так как название пакета будет служить уникальным идентификатором вашего приложения. Например, ниже в моем случае названием пакета служит «com.maverics.eugene.telephonelist»:

При этом если в файлах кода java название пакета в начале файла также должно соответствовать пакету приложения.

Установка требований

На этапе подготовки к релизу также можно установить требования к API. Например, наше приложение имеет определеную минимальную версию ОС Android, поэтому мы можем установить в файле манифеста соответствующие атрибуты у элемента <uses-sdk>

android:minSdkVersion — минимальная версия Android

android:targetSdkVersion — оптимальная версия API

android:maxSdkVersion — максимальная версия системы

Например, пусть минимальная версия Jelly Beans 4.1.2, а оптимальная KitKat 4.4.4:

Подпись приложения

Когда все уже готово, приложение для Android должно быть подписано сертификатом, благодаря которому можно идентифицировать автора приложения. Когда мы тестируем приложение, устанавливая его через Android Studio на устройство, то оно подписывается автоматически. Но для создания релиз-версии нам надо произвести дополнительно ряд действий.

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

Во-первых, в Android Studio выберем в меню пункт Build -> Generate Signed APK . После этого нам откроется окно мастера:

Нажмем на кнопку Create new. . После этого нам откроется окно создания ключа:

Введем в поле Key store path путь к файлу сетификата, который будет создан. Если указанной папки не существует, то ее надо создать или определить существующую папку.

В поле Password/Confirm указываем пароль.

В поле Alias указываем псевдоним. Можно поставить произвольное название.

В поле First and Last Name вписываем имя и фамилию. И далее пишим подразделение, организацию, город, страну и код страны.

В конце нажимаем OK.

После этого автоматически обновится первое окошко:

Далее нажмем на кнопку Next:

Финальное окно покажет нам путь к каталогу, где будет находиться подписанное приложение apk в release-версии. Нажмем на Finish.

Теперь по указанному пути можно будет найти подписанный apk, который будет иметь название app-release.apk:

Мы можем переименовать файл, сохранив его расширение и выложить в Play Market или на любой сайт или сразу загрузить на мобильное устройство. После загрузки на телефон/планшет достоточно нажать на него, и с помощью стандартного установщика пакетов приложение будет установлено. Правда, здесь также надо учитывать, что если мы устанавливаем приложение не из Play Market, то в настройках надо разрешить установку из других источниках — Безопасность->Неизвестные источники (Разрешить установку приложений из других источников)

Мама, я хакер: пробуем вскрыть приложение на Flutter

Hacker — человек, наслаждающийся доскональным пониманием внутреннего устройства систем, компьютеров и компьютерных сетей, в частности.

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

Мама! Ну сколько раз тебе говорить, я не нахер, я — ХАКЕР!

В достаточно далёком, по меркам IT-технологий, 1989 году, я стал счастливым обладателем своего первого персонального компьютера «Ассистент», с неплохими характеристиками для домашнего ПК на тот момент – Intel совместимым процессором 8086 на 5МГц и памятью 128Кбайт. А еще был железный (в прямом смысле слова) матричный принтер фирмы Robotron, который, зараза, неправильно печатал одну из букв в русской раскладке. В общем, волею судьбы, первым моим опытом реверс-инжиниринга стал разбор кода работы BIOS при выводе на печать и создание на ассемблере небольшого перехватчика прерывания, который подменял букву на нужную. В результате, в памяти хорошо запомнился восторг того юного начинающего хакера-пионера, и я безразмерно благодарен своим родителям, которые, отказавшись от своих «хотелок» тогда, приобрели мне не самый дешёвый компьютер по тем временам, поддержав мой интерес к вычислительной технике.

С тех пор, периодически занимался этой темой, правда, в основном, не профессионально. Это были или лично интересные для меня задачи, например исследования вирусов, защит ПО от взлома, или нечастые смежные задачи по работе. Занимался реверс-инжинирингом приложений под DOS/RT-11/Windows/Linux, в том числе приложений для .NET Framework, серверных приложений на Java, прошивок встраиваемых систем с различными процессорными архитектурами. В настоящее время, реверсом практически не занимаюсь, но, поскольку IT-фортуна свела меня с Flutter, решил вспомнить «молодость» и попробовать «на зубок» мобильные приложения, созданные с помощью этого замечательного фреймворка.

В общем, достаточно лирики. Итак, кому интересна магия превращения исходного кода на Dart в приложение Android и насколько сложно «взломать» его, с точки зрения хакера-любителя, добро пожаловать под кат.

Объект исследования

В качестве объекта для эксперимента, был написан небольшой пример, задача которого банальна — проверить корректность ввода пароля. Сам пароль хранится в исходном коде как константа (конечно, никогда так не делайте). При вводе пароля производится сравнение и выводится приветствие или, в противном случае, соответствующее предупреждение. Исходники этого нано-приложения расположены здесь.

Сейчас мы отступим от кодекса честного хакера и перейдем на темную сторону взломщиков crackers (по RFC 1983). Для примера используем хорошо известный приём «взлома», это замена условного оператора сравнения на противоположный по смыслу, т. е. если изначально в условии стоит «не равно» подменяем его на «равно». Во многих системах это осуществляется просто заменой одного байта машинного кода или промежуточного кода (например, для IL .NET Framework) в скомпилированном исполняемом файле, который запускает пользователь. При этом одна из самых главных задач – найти это место в скомпилированном файле.

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

Итак, наша цель — без модификации исходного кода, имея на руках только скомпилированный apk файл приложения Android, понять, как работает код, найти место сравнения и заменить условный оператор, после этой манипуляции подойдет любой пароль, который вводит пользователь (конечно, кроме корректного).

Перепонтовался

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

Не знаю хорошо это или плохо, в общем — у меня это не получилось. Поэтому, если у кого был вопрос — сложнее ли взломать «обычное» Android приложение или Flutter? — При прочих равных условиях и исходя из своего скромного опыта, Flutter сегодня существенно труднее поддается реверс-инжинирингу. И если для обычных приложений на Android, накоплен достаточный опыт, и мы имеем различные инструменты – например, можем получить Java код из dex/jar файлов приложения, или Smali код, то для Flutter все «грустно», ввиду отсутствия инструментов и практик. Пока фреймворк не так популярен, хотя, в случае роста популярности, возможно появятся и инструменты, и более конкретные кейсы. Поэтому, простите меня профессиональные хакеры, далее речь пойдет только о процессе компиляции и замене машинного кода приложения в заранее известном месте.

Инструменты

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

apktool – популярный инструмент для реверс-инжиниринга приложений под платформу Android

keytool – утилита управления сертификатами и ключами

jarsigner – утилита подписи Java архивов

adb – стандартный инструмент для работы с подключенными к компьютеру Android устройствами

hopper – дизассемблер для MacOS и Linux

расширение для VSCode позволяющие редактировать файлы в шестнадцатеричном режиме

Все действия производились на MacOS.

Debug&Release

Во Flutter существует несколько режимов сборки приложения. Для целей статьи мы рассмотрим основные – это debug и release режимы.
Debug в этом режиме, кроме того, что там по умолчанию включены различные дополнения, помогающие разработчику при отладке, используется так называемая JIT (Just-In-Time) компиляция, в вольном переводе «прямо-во-время», по сути преобразование в машинные коды, которые понимает процессор мобильного устройства, происходит непосредственно во время работы самого приложения.

Release режим использует уже AOT (Ahead-Of-Time) буквально «заранее», компиляция приложения из исходных кодов в машинные коды мобильного устройства производится на машине разработчика, и на устройство пользователя устанавливается уже скомпилированное приложение, никаких преобразований во время выполнения не производится.

У этих 2-х режимов есть одно общее – это AST представление. При компиляции исходных кодов они предварительно переводятся в промежуточное представление AST (Abstract-Syntax-Tree), это представление может сохраняться в специализированном формате как Kernel Binary (как правило это файлы с расширением dill).

Именно это представление передается в мобильное устройство при JIT компиляции в режиме Debug и используется как промежуточный шаг при переводе в машинные коды в режиме AOT. Далее это представление преобразуется в граф управления и переходов (CFG), содержащий инструкции промежуточного кода IL, эти инструкции затем переводятся непосредственно в машинный код, который понимает процессор мобильного устройства.

По поводу различия в скорости работы JIT и AOT: JIT хотя и использует преобразование в машинный код непосредственно на устройстве пользователя и затрачивает на это некоторое время, результирующий машинный код может быть быстрее в некоторых случаях, так как может на лету анализировать типы объектов по месту использования (да, да – тот самый полиморфизм) и генерировать оптимальный код исходя из текущего контекста исполнения, но поскольку в iOS подход JIT не разрешен, для release режима сейчас используется только AOT.

Собираем Debug

Для начала попробуем собрать наш проект в режиме debug. Выполняем в терминале команду flutter build apk —debug

так как собраный файл APK это, по сути, zip архив, распаковываем и смотрим что там внутри

Содержимое app-debug.apk

Из всех компонентов можно выделить файлы, предназначенные для интеграции Flutter с платформой Android:

classes.dex – файл классов для виртуальной машины Dalvik, в обычных приложениях как раз в этом файле находится скомпилированный Java/Kotlin байт-код приложения. В случае с Flutter там находится код связи Flutter приложения с Android API, например — главный FlutterActivity, работа с объектами поверхностей рисования на виртуальном дисплее, код для связи с платформенными каналами

libflutter.so – менее платформозависимая библиотека движка Flutter написанная в основном на C/C++. В библиотеке находится runtime для работы Flutter, код OpenGL, SKIA и runtime виртуальной машины Dart. Более подробней c составом этих файлов можно ознакомиться в скрипте сборки GN

Что касается именно нашего кода проекта, он расположился в следующих файлах:

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

vm_snapshot_data общие объекты виртуальной машины Dart используемые изолятами

kernel_blob.bin, вот здесь и хранится наш код в формате kernel binary, а также весь код фреймворка написанный на Dart. Причем это blob файл, т. е. там может храниться различная мета информация о коде кроме самого kernel binary, в случае debug сборки там также хранится весь исходный код нашего приложения включая комментарии.

На самом деле модификация debug сборки не представляет интерес, так как там практически хранится все в «открытом» виде. Поэтому, для целей нашей статьи, перейдем к исследованию сборки в режиме release.

Собираем Release

Выполняем команду flutter build apk

Для получения полного лога о процессе сборки используется флаг —verbose , он покажет гораздо больше информации, что так же может быть полезным при диагностике проблем. В логе можно увидеть, что процесс компиляции нашего проекта проходит этап преобразования в AST представление, при этом генерируется файл app.dill, затем применяется инструмент gen_snapshot, он создает из app.dill скомпилированный в машинный код файл библиотеки libapp.so, который уже помещается в APK файл.

Содержимое app-release.apk

Содержимое app-release.apk

В сборке release находятся те же файлы classes.dex и libflutter.so, что и в сборке debug, правда они уже не такие «жирные», так как исключены многие компоненты, используемые для отладки. По сравнению с debug сборкой видим отсутствие файлов isolate_snapshot_data, vm_snapshot_data, но, если заглянуть в libapp.so, увидим, что теперь эти компоненты разместились здесь, а kernel_blob.bin был преобразован в машинный код и размещен в секциях _kDartIsolateSnapshotInstructions и _kDartVmSnapshotInstructions библиотеки.

Ещё можно увидеть, что все ресурсы (assets) программы хранятся в папке flutter_assets, соответственно их также можно свободно извлечь и модифицировать при необходимости.

На этом мои изыскания затормозились, ибо декодирование файла libapp.so, что не удивительно, отображает только ассемблерный код. Инструментов декомпиляции Dart кода хотя бы в промежуточный IL, не говоря уже о AST или Dart я не нашел. С учётом процесса компиляции, конечно, можно представить и обратный процесс – это поиск точек входа, использование описания объектов из секции информации об объектах (_kDartIsolateSnapshotData), преобразование в несколько проходов из ассемблера в IL и граф переходов, затем в kernel binary и, наконец, в Dart. Но, данная работа выходит далеко за рамки объема времени, который я предполагал выделить на эту статью.

Место модификации

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

Сравнив 2 файла, было видно, что они отличаются только в одном байте, что не может радовать хакера-любителя, так как это позволяет изменить просто один байт, не затрагивая размер и композицию файла. Соответственно, чтобы изменить поведение приложения на противоположное надо заменить только один байт.

Для исследования был взят libapp.so для архитектуры arm64, которая используется в процессоре на моем телефоне. Если посмотреть на участок кода ассемблера в котором есть изменения, то можно увидеть, что они касаются команды тестирования и перехода. Соответственно заменив tbnz на tbz мы получим необходимый нам результат.

Само преобразование IL кода в машинный код находится в Dart sdk, в файле отвечающим за соответствующую архитектуру. Например для assembler ARM64 она находится здесь. Если проследить цепочку вызовов можно выйти и на компилятор flowgraph и IL. Здесь мы видим, что большинство кода компиляции используется как для JIT, так и для AOT режимов.

Для тех, кому интересна компиляция и процессы преобразования, Dart SDK предоставляет такую возможность.

Пример консольного приложения main.dart

Команда отображающая при запуске информацию о IL, CFG и коде ассемблера
dart —print-flow-graph —print-flow-graph-filter=main —disassemble main.dart

Пример участка скомпилированного кода, выполняющий операцию сравнения

Акт последний — модификация APK

Закончим наш эксперимент заменой соответствующего байта условного оператора в скомпилированном apk файле. Это операция состоит из нескольких этапов:

Разборка apk файла

Модификация libapp.so с заменой байта

Сборка модифицированного apk

Установка на смартфон и проверка

Разбираем исходный файл используя инструмент apktool

apktool d -r -s app-release.apk

Эта команда распакует в каталоге app-release компоненты нашей релизной сборки. Поскольку сейчас интересует именно архитектура arm64 возьмем libapp.so из каталога lib/arm64-v8a и с помощью шестнадцатеричного редактора заменим байт в файле.

Замена байта по смещению 0x1FFCA7 на 0х37

После модификации libapp.so переcобираем apk

apktool b app-release

Поскольку мы изменили содержимое файлов архива APK, при установке этого файла сработает защита проверки подписи. Чтобы обойти это, нам необходимо подписать файл своей подписью. Можно использовать существующий ключ или создать новое хранилище ключей командой
keytool -genkeypair -v -keystore example.keystore -alias example -keyalg RSA -keysize 2048 -validity 10000

Подписываем файл apksigner sign —ks example.keystore —ks-key-alias example app-release.apk

Устанавливаем на устройство adb install app-release.apk

Запускаем наше приложение, и. теперь подходит любой пароль! Мы изменили поведение приложения без использования исходных файлов.

Резюме

Хотя полностью провести реверс-инжиниринг мне не удалось, по результатам работы над статьей можно сделать вывод – исследование без исходных кодов внутренней работы приложения на Flutter выполнить сложнее чем «обычного» приложения под Android. Что касается именно «взлома», конечно декомпиляция является не единственным инструментом для достижения целей взломщиков – у них есть целый арсенал как прокси-серверов, инструменты для SQL-unpinning, инъекций кода, я уже не говорю про социальную инженерию. Поэтому, изначально, можно предполагать, что при необходимости и целесообразности весь код приложения может быть просмотрен и изучен, а также проведена его соответствующая модификация в различных целях. Поэтому важна целостная картина безопасности инфраструктуры и бизнес-контекста, в котором работает мобильное приложение. Но, это совершенно отдельная тема, которая пересекается с этой статьей только в части реверс-инжиниринга.

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

Build and release an Android app

You have two possible release formats when publishing to the Play Store.

• App bundle (preferred)
• APK

Build an app bundle

This section describes how to build a release app bundle. If you completed the signing steps, the app bundle will be signed. At this point, you might consider obfuscating your Dart code to make it more difficult to reverse engineer. Obfuscating your code involves adding a couple of flags to your build command, and maintaining additional files to de-obfuscate stack traces.

From the command line:

1. Enter cd [project]
2. Run flutter build appbundle –build-number=1 –build-name=1.00
   (Running flutter build defaults to a release build.)

The release bundle for your app is created at [project]/build/app/outputs/bundle/release/app.aab .

By default, the app bundle contains your Dart code and the Flutter runtime compiled for armeabi-v7a (ARM 32-bit), arm64-v8a (ARM 64-bit), and x86-64 (x86 64-bit).

Test the app bundle

An app bundle can be tested in multiple ways—this section describes two.

Offline using the bundle tool

1. If you haven’t done so already, download bundletool from the GitHub repository. from your app bundle. to connected devices.

Online using Google Play

1. Upload your bundle to Google Play to test it. You can use the internal test track, or the alpha or beta channels to test the bundle before releasing it in production.
2. Follow these steps to upload your bundle to the Play Store.

Build an APK

Although app bundles are preferred over APKs, there are stores that don’t yet support app bundles. In this case, build a release APK for each target ABI (Application Binary Interface).

If you completed the signing steps, the APK will be signed. At this point, you might consider obfuscating your Dart code to make it more difficult to reverse engineer. Obfuscating your code involves adding a couple of flags to your build command.

From the command line:

1. Enter cd [project]
2. Run flutter build apk —split-per-abi –build-number=1 –build-name=1.00
   (The flutter build command defaults to —release .)

This command results in three APK files:

• [project]/build/app/outputs/apk/release/app-armeabi-v7a-release.apk
• [project]/build/app/outputs/apk/release/app-arm64-v8a-release.apk
• [project]/build/app/outputs/apk/release/app-x86_64-release.apk

Removing the —split-per-abi flag results in a fat APK that contains your code compiled for all the target ABIs. Such APKs are larger in size than their split counterparts, causing the user to download native binaries that are not applicable to their device’s architecture.

Install an APK on a device

Follow these steps to install the APK on a connected Android device.

From the command line:

1. Connect your Android device to your computer with a USB cable.
2. Enter cd [project] .
3. Run flutter install .

Publishing to the Google Play Store

For detailed instructions on publishing your app to the Google Play Store, see the Google Play launch documentation.

App release apk что это

Obtainium
Версия: 0.13.11

Последнее обновление программы в шапке: 25.06.2023

Краткое описание:
Obtainium позволяет вам устанавливать и обновлять приложения с открытым исходным кодом непосредственно со страниц их выпусков и получать уведомления о релизах.

Если вы пользуетесь только Google Play Маркет для установки и обновления приложений на Android, то проблем возникнуть не должно. Далеко не все альтернативные магазины приложений умеют автоматически обновляться в фоне или в целом самостоятельно искать и уведомлять о выходе новых версий.

Если же вы установили приложение через apk-файл (или файл с другим расширением) и у приложений или игры нет встроенной системы обновления, то обновлять придется вручную, а это не столь удобно. К тому же, многие и вовсе могут забыть про обновления и не получать новых возможностей или обновлений безопасности.

Организовать обновление из различных источников поможет приложение Obtainium. Оно позволит искать новые версии приложений и устанавливать их в едином интерфейсе. Пользователю не нужно будет искать приложения в различных магазинах или на официальных сайтах. Поддерживается обновление приложений в таких источниках как: GitHub, GitLab, F-Droid, IzzyOnDroid, Mullvad, Signal и SourceForge.

• GitHub
• GitLab
• Codeberg
• F-Droid
• IzzyOnDroid
• Third Party F-Droid Repos
  [Any URLs ending with /fdroid/, where can be anything — most often repo]
• «HTML» (Fallback)
  [Any other URL that returns an HTML page with links to APK files (if multiple, the last file alphabetically is picked)]
• APKMirror (Track-Only)
• SourceForge
• Steam
• Mullvad
• Signal

Требуется Android: 6.0 и выше
Русский интерфейс: Да

Разработчик: ImranR98
Домашняя страница: https://github.com/ImranR98/Obtainium
Имя пакета: dev.imranr.obtainium

Сообщение отредактировал aaaquarius — 25.06.23, 10:01

Fixgrab, добавьте ссылку приложееия на гитхабе например

Fixgrab, ну да, это как подписка на rss, у меня не так много приложух, со временем добавлю необходимое, если приложение зайдет, пока тестирую

Сообщение отредактировал eXense — 17.10.22, 18:54

Конечно же ещё нужна поддержка Gitea, Codeberg, sourcehut и некоторых других. Но всё зависит от количества подключившихся к проекту программистов.

Какие-то ещё конкурирующие приложения видели?

По поводу необходимости добавления в этот клиент F-Droid, IzzyOnDroid и их репозиториев я не уверен. У нас есть достаточно клиентов на любой вкус. Лучше уж сосредоточиться на GitHub и альтернативах.

+ Приложение не имеет лишних разрешений. Трекеров на данный момент не обнаружено (но это ничего не значит, частенько на более поздних стадиях любят впихивать ACRA).

Сообщение отредактировал sol4r1s — 24.10.22, 06:08

krolaper, пока ещё не показывается Changelog релизов на GitHub. Но добавлять удобно.
Если есть только исходники приложения, то будет ошибка добавления в мониторинговую базу. Поэтому следить за развитием каких-то сервисов не получится. Нужен обязательно .apk.

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

Сообщение отредактировал sol4r1s — 24.10.22, 07:15

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

Из багов обнаружил: нерабочий экспорт, сброс фильтров после перезахода.

Из моих пожеланий: список изменений, выбор версии(на случай неудачного обновления).

Сообщение отредактировал Nilme — 24.10.22, 10:03

Тип: Новая версия
Версия: 0.6.2-beta
Краткое описание: github
фиксы

v0.6.2-beta
Fixes #73, #74, #75.
https://github.com/Imr…leases/tag/v0.6.2-beta
если коротко, то в этой бете чинились баги при взаимодействиях с f-droid.

v0.6.1-beta
Bugfix: Mass install option was not working (especially bad considering this is needed to upgrade to the last 0.6.0 release).

• Fixes #14 (although detection is disabled in background processes due to the bug described in #60)
• Real Package Names Used as IDs (INCONVENIENT FOR PREVIOUS VERSION USERS)
• Enables installed detection (no longer need to manually mark Apps as installed/not installed)
• Switch to using extracted names (no custom names)

• Fixes #57
• Fixes #67
• Fixes #64
• Fixes #61

• Commented out APKMirror and added code to remove their Apps (see #44)
• The relevant code still exists and can be re-enabled, but there are no guarantees that it works, and it may be removed completely in the future.
• Switched to Flutter stable (causes some UI elements to switch back to the old material design style, but this will be fixed in later Flutter releases)
• BG task silently retries on network errors
• Updated README
• Updated screenshots

Сообщение отредактировал sol4r1s — 30.10.22, 12:11

eXense, с иконками стало приятней и информативней.
Когда обновляется инфа про конкретное приложение, то пиктограмма его мигает.
История изменений пока представлена как ссылка на страницу с релизами.

В бетах активно разбираются с жуками.

Ждём добавления новых репозиториев. Я свои хотелки уже озвучил.

• Fixes #104 and one other UI bug.
• Fixed bug in GitHub regex filtering caused by recent change (#20).
• Update notifications now get cancelled when an App is installed as this likely means the user has seen it already (#101).
  (Ideally, update notifications should only be cancelled if the Apps being installed are the actual Apps mentioned in the notification, but there is no way to get his info from the notification (see MaikuB/flutter_local_notifications#1700), so the compromise is to just get rid of all update notifications when any app at all is installed or updated.)
• Add arch info by @Marusiella in #100
  (Adds a note about supported CPU architectures to the APK picker as a hint to help the user pick a supported APK.)
• Switched from WorkManager to AlarmManager plugin to fix #87
• Code cleanup (#70) and some bugfixes
• Fixes #88, #89, #90:
  1. Adds a progress indicator when checking for updates manually.
  2. Adds an option to pin available updates to the top of the Apps list (on by default).
  3. Fixes blinking/flickering App icons on update check.
• Fixes #84 — Apps would not update correctly if Obtainium was included in the update list.
• Fixes #77, #78, #79.

С 0.6.5 делают сборки для разных архитектур. Это положительно сказалось на размере пакета.

* Обновлённые пакеты апает на вершину списка. Если по какой-то причине не нравится такое поведение, то его можно отменить в Настройках.
* Полоса прогресса во время обновления делает процесс приятней (индикация в виде помигивания иконок ушла в прошлое).
* По добавлениям репозиториев пока никак (ведь SourceForge был?): допиливают оболочку. Скорей всего потом уже будут расширять ассортимент источников: для сырого приложения их и без того много.