этот объект app bundle содержит нативный код

Создание проекта под Android

Помощь в написании контрольных, курсовых и дипломных работ здесь.

Построение unity проекта под платформу android?
Как сделать что бы после сборки проекта в unity под android формировался не apk файл а sln решение.

Создание программ под Android на Unity 3d
Установила Unity 3d 4, чтобы создавать программы под Android. В интернете весь обучающий материал.

Компиляция проекта на C++ под Android
Здравствуйте уважаемые программисты! Подскажите пожалуйста, как готовыq проект на С++.

Портирование проекта под android на ios
Доброго времени суток, возможно ли, разрабатывая игру на C++ под Android портировать без особых.

oleg rus,

Конкретно по Keystore начинается с 3:15. Но советую посмотреть весь ролик по настройке.
Так же нужно знать, что Google play уже не принимает проекты без поддержки ARM64 Для этого в настройках билда нужно сделать так как на картинке.

Важно!
После загрузки подписанного билда в Play Market, вы не сможете изменить файл Keystore для этого проекта. По этому сохраните файл цифровой подписи в надежном месте и запомните пароль. Восстановление крайне сложный процесс! Так же при каждом новом билде, нужно будет каждый раз указывать ссылку на файл ключа и вводить пароль к нему.

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ‘:signReleaseBundle’.
> 1 exception was raised by workers:
java.lang.RuntimeException: jarsigner.exefailed with exit code 1 :
jarsigner error: java.lang.RuntimeException: keystore load: Keystore was tampered with, or password was incorrect

BUILD FAILED in 2m 36s
]
stdout[

> Configure project :
WARNING: The option setting ‘android.bundle.enableUncompressedNativeLibs=false’ is experimental and unsupported.
The current default is ‘true’.

> Task reBuild UP-TO-DATE
> Task reReleaseBuild
> Task :compileReleaseRenderscript NO-SOURCE
> Task :generateReleaseResValues
> Task :generateReleaseResources
> Task :mergeReleaseResources
> Task :checkReleaseManifest
> Task :createReleaseCompatibleScreenManifests
> Task :mainApkListPersistenceRelease
> Task rocessReleaseManifest
> Task :bundleReleaseResources
> Task :mergeReleaseShaders
> Task :compileReleaseShaders
> Task :generateReleaseAssets
> Task :mergeReleaseAssets
> Task :checkReleaseDuplicateClasses
> Task :compileReleaseAidl NO-SOURCE
> Task :generateReleaseBuildConfig
> Task repareLintJar
> Task :generateReleaseSources
> Task :javaPreCompileRelease
> Task rocessReleaseResources
> Task :compileReleaseJavaWithJavac
> Task :transformClassesWithDexBuilderForRelease
> Task :transformDexArchiveWithExternalLibsDexMergerForRelease
> Task :transformDexArchiveWithDexMergerForRelease
> Task :mergeReleaseJniLibFolders
> Task :transformNativeLibsWithMergeJniLibsForRelease
> Task :transformNativeLibsWithStripDebugSymbolForRelease
> Task rocessReleaseJavaRes NO-SOURCE
> Task :transformResourcesWithMergeJavaResForRelease
> Task :buildReleasePreBundle
> Task :collectReleaseDependencies
> Task :configureReleaseDependencies
> Task ackageReleaseBundle
> Task :validateSigningRelease
> Task :signingConfigWriterRelease
> Task :signReleaseBundle FAILED

Источник

Playstore error: App Bundle contains native code, and you’ve not uploaded debug symbols

When I want to release a new flutter app bundle to the Playstore. I get this error: «This App Bundle contains native code, and you’ve not uploaded debug symbols. We recommend you upload a symbol file to make your crashes and ANRs easier to analyze and debug.» I can’t find any way to fix this. I’m new with flutter and releasing app’s and getting a bit desperate. Any help would be fantastic.

When I add «android.defaultConfig.ndk.debugSymbolLevel = ‘FULL'» (on line 1) to the app/build.gradle as suggested in https://developer.android.com/studio/preview/features#native-crash-symbolization. I get This error in the Android studio terminal. I use this command «flutter build appbundle».

Error in Terminal: FAILURE: Build failed with an exception.

Where: Build file ‘C:\Users\filip\AndroidStudioProjects\ehbo\android\app\build.gradle’ line: 1

What went wrong: A problem occurred evaluating project ‘:app’.

Could not get unknown property ‘android’ for project ‘:app’ of type org.gradle.api.Project.

BUILD FAILED in 3s Running Gradle task ‘bundleRelease’. Running Gradle task ‘bundleRelease’. Done 4,3s Gradle task bundleRelease failed with exit code 1

10 Answers 10

Before you can upload debug symbols files, you must be using Android Gradle plugin version 4.1 or higher.

Looks like it will come only with Android Studio 4.1, because I can only get Gradle 4.0.0 automatically now.

So I suggest you to return classic Play console and it will let you through 🙂

If talking about Flutter, looks like the Flutter team needs to change some source files for the NDK, because it does not see where from to generate debug symbols.

Setup steps are so:

Install NDK (Side by Side) in SDK manager

Write path to NDK in local.properties

Add in app/build.gradle (last line) android.buildTypes.release.ndk.debugSymbolLevel = ‘FULL’

The Answer was given by Shakle will be not useful as per the following message on Play Console.

The old version of Play Console will be discontinued from November 2, 2020 You’re already using the new Play Console, so you don’t need to do anything. A few features are going away if you want to check them one last time.

It’s just a warning, nothing else. Just go ahead.

If you don’t want any warning, Go to this link and follow the steps:

You can use the new version of the play store as it is.

you can make these zip file by go to build\app\intermediates\merged_native_libs\release\out\lib inside your flutter project

If you want to solve this warning error: This App Bundle contains native code, and you’ve not uploaded debug symbols. We recommend you upload a symbol file to make your crashes and ANRs easier to analyze and debug. Make sure also to install CMake

This will happen if your gradle version is higher than 4.0 Place this code into your build.gradle file

Reproduce next steps and this warning will disapear

note that exist 3 folders inside

Could not get unknown property ‘android’ for project ‘:app’ of type org.gradle.api.Project.

You have to add it in gradle.properties not build.gradle

I have the exact same issue.

For fixing it in the Visual Studio Code: you should first download the NDK from the android’s website.

Under the Android section. Add ndkPath property as follows: ndkPath =

At the end of app/build.gradle add android.buildTypes.release.ndk.debugSymbolLevel = ‘full’

The next appbundle, built by flutter build appbundle command should not give any errors on play store about native debug symbols.

more thorough explanation is here

I was able to get Flutter to build native debug symbols using Android Gradle Plugin (AGP) 4.1.0, installing corresponding NDK version and adding the appropriate config to android/app/build.gradle on macOS (but it should also work on Windows/Linux).

Troubleshooting: If you get any errors around CMake I didn’t explicitly install it but you might need to, especially if you’re using Windows, and you can do so using Android Studio.

Источник

Новый способ публикации приложений с помощью Android App Bundle

На недавно прошедшей Google I/O 2018, среди множества нововведений, объявили также о добавлении нового формата приложений.

Этот формат получил название Android App Bundle и представляет собой улучшенный способ сборки вашего приложения. С его помощью можно легко оптимизировать размер приложения, при этом не нужно будет вносить какие-либо изменения в код. Android App Bundle включает весь скомпилированный код и ресурсы, отсеивая затем то, что не нужно конкретному устройству.

Важно! На данный момент Android App Bundle работает только в preview-версии Android Studio. Последняя версия Android Studio 3.2 Canary доступна здесь.

Формат Android App Bundle

Android App Bundle представляет собой файл (с расширением .aab), который загружается в Google. Каждый бандл включает скомпилированный код и ресурсы для всех модулей приложения и поддерживаемых конфигураций устройств.

Проще говоря, бандлы это подписанные ZIP-файлы, которые упорядочивают код и ресурсы приложения в модули.

Из этих модулей Google Play генерирует различные APK, которые предоставляются пользователям, такие как: базовые APK, dynamic feature APK, конфигурационные APK и (для устройств, которые не поддерживают разделённые APK) мульти-APK. Каталоги, окрашенные в синий цвет, представляют собой код и ресурсы, которые Google Play использует для создания конфигурационного APK для каждого модуля.

Примечание: бандл нужно создавать для каждого уникального приложения или applicationID. То есть, если вы используете несколько product flavor в своём приложении для создания различных APK, и каждая из этих веток использует уникальный applicationID, то вам нужно будет создать отдельный бандл для каждой ветки.

Код и ресурсы для каждого модуля организованы аналогично стандартным APK, и это логично, поскольку каждый из этих модулей может быть сгенерирован как отдельный APK. Ниже можно увидеть более подробное описание некоторых файлов и каталогов Android App Bundle:

Сборка App Bundle с помощью Android Studio

Создание бандла с помощью Android Studio очень похоже на создание APK. Для сборки достаточно выбрать в меню Build — Build Bundle(s)/APK(s) > Build Bundle(s) и IDE создаст бандл для выбранного варианта сборки и разместит его в каталоге

Если создаётся бандл для debug-версии приложения, Android Studio автоматически подпишет бандл с помощью отладочного ключа подписи. Для загрузки бандла в Google Play он должен быть подписан.

После того, как Android Studio завершит создание подписанного бандла, его можно будет открыть и проанализировать. Анализ бандла позволяет проверить содержимое и работает аналогично APK Analyzer.

Для создания App Bundle IDE использует тот же инструмент с открытыми исходным кодом, называемый bundletool, который Google Play использует для последующего преобразования бандла в подписанные APK.

Прежде чем загрузить бандл в консоль Google Play, его нужно подписать. Чтобы создать подписанный App Bundle, нужно выполнить следующие действия:

После того, как Android Studio завершит создание подписанного бандла, его можно будет найти и проанализировать, выбрав соответствующую опцию во всплывающем уведомлении. Если был выбран экспорт ключа подписи, то к нему можно будет быстро перейти, щёлкнув по стрелке вниз в правом нижнем углу всплывающего уведомления, чтобы развернуть его, и затем выбрав Show Exported Key File.

Загрузка App Bundle в консоль Google Play

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

Анализ APK с помощью проводника

Когда бандл загружен, Google Play автоматически генерирует разделённые APK и мульти-APK для всех конфигураций устройств, поддерживаемых приложением. В Play Console можно можно использовать App Bundle Explorer для просмотра всех вариантов APK, сгенерированных Google Play; анализа данных, таких как поддерживаемые устройства и экономия размера APK; загрузки созданных APK для тестирования.

Обновление приложения

После загрузки приложения в Play Console, для обновления приложения достаточно повысить код версии, а также создать и загрузить новый бандл. Затем Google Play сгенерирует обновлённые APK с новым кодом версии и будет предоставлять их по мере необходимости.

Заключение

Использование Android App Bundle даёт большие преимущества для оптимизации APK приложений. С помощью этого способа мы обновили одно из наших приложений, «Менеджер паролей от Wi-Fi сетей«, заменив в нём стандартный APK на App Bundle. Таким образом, размер APK файлов уменьшился на целый мегабайт, что является очень хорошим результатом.

Кроме того, Google на данный момент тестирует дополнение к App Bundle, Dynamic feature modules, с помощью которого можно разбивать базовый APK на части, которые будут докачиваться при необходимости, пока что эта технология находится в бета-версии.

Возможно, единственным недостатком банлдов на данный момент назвать необходимость использовать preview-версию Android Studio, однако эта проблема временная.

Источник

Как Android пришел к AAB? Что будет с APK? Разбор

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

Проблема Android

У системы Android есть одна очень важная особенность, которая является как огромным преимуществом, так и огромной проблемой.

Поэтому вся история развития системы Android — это история борьбы, компромиссов и поиска баланса.

Условно историю Android можно поделить на 4 этапа: когда Android тормозил, много жрал, оптимизировался и, наконец, находился в балансе.

Этап 1. Dalvik: Android тормозит

Этап 2. ART: Android потребляет

Этап 3. Profiling: Android оптимизируется

Этап 4. AAB: Android балансирует

И сегодня мы поговорим про все четыре этапа. Но начнём с небольшой ремарки.

Чтобы соблюсти первые два базовых требования к системе, а именно: поддержка разных архитектур и простота программирования. В качестве основного языка программирования в системе Android была выбрана Java. Почему так?

У Java есть несколько классных свойств: он изначально был создан как мультиплатформенный: пишешь один раз — работает везде.

Но, есть и недостаток. Достигается это всё очень грязными методами, а именно при помощи виртуальной Java-машины. Тут стоит пояснить.

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

Нативные приложения — самые быстрые, потому они записаны на языке понятном железу. А теперь смотрите внимательно: приложения написанные на Java компилируется не в нативный код, а в промежуточный код, который называется байт-кодом.

А вот уже из этого байт-кода можно достаточно быстро перевести приложение под любую архитектуру при помощи виртуальной Java-машины.

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

И Android-приложения — не исключение.

Единственное что, в Android вместо виртуальной машины Java используется собственная, куда более эффективная, виртуальная машина Dalvik или ART. А также вместо байт-кода Java используется собственный, куда более эффективный, байт-код, который внутри APK-шек записыватся в файлах с расширением DEX (анимация).

Тем не менее, это не меняет сути, т.к. Android-приложения содержат много Java-кода и это проблема, которую как-то нужно решать. Так вот на протяжении своей истории эта проблема решалась по-разному.

ЭТАП 1. Dalvik: Android тормозит

Вплоть до Android версии 4.4 KitKat приложения запускались через виртуальную машину Dalvik, которая работала по принципу Just In time компиляции или JIT-компиляции. То есть приложения транслировались в нативный код прямо во время исполнения, то есть “на лету”.

Мы уже рассказывали про JIT-компиляцию в ролике про Android на Windows 11, если не видели — посмотрите. Е

Ответ простой: такой подход позволял экономить много памяти — в первую очередь, оперативной. Тогда устройства были не такие мощные как сейчас, у многих на борту было не больше 200 Мб ОЗУ. А JIT-компиляция позволяла, так сказать, загружать в оперативку только ту часть приложения, которая используется.

Плюс ко всему, сам по себе байт-код компактный, поэтому и на диске приложения занимали очень мало места.

Да и были возможности оптимизации: скомпилированный код можно записать в кэш и дальше уже из кэша брать как бы нативный код. В общем, можно жить…

Помните же Dalvik-кэш? Вот это как раз он…

ЭТАП 2. ART: Android потребляет

Тем не менее пользователи и приложения становились всё более требовательными к отзывчивости. И в Android 4.4 KitKat была представленная новая виртуальная машина ART или Android Runtime. А в Android 5.0 Lollipop ART полностью заменила Dalvik.

Вместе с новой средой выполнения, Android поменял стратегию на 180 градусов. Вместо компиляции во время исполнения приложения ART стала использовать компиляцию перед исполнением. То есть компиляция теперь делается во время установки приложения. Такой вид компиляции называет Ahead Of Time компиляция или сокращенно AOT-компиляция.

И естественно, Android залетал! Приложения стали быстрее запускаться и работать без каких либо дополнительных задержек. Фактически все приложения внезапно стали “нативными” для железа!

Вообще согласитесь, Android 5-й версии был хорош. Система летала, представили Material Design… Просто счастье.

ЭТАП 3. Profiling: Android оптимизируется

Поэтому в Google подумали: компилируя приложение целиком, не делаем ли мы лишнюю работу? А вот и делаем!

Как выяснилось, по статистике пользователи очень редко используют более 10-20% кода приложения. Иными словами, в большинстве случаев заранее будет достаточно скомпилировать только малую часть, которая будет действительно использоваться часто, а для редких уголков приложения, в которые мы не заходим, можно будет и JIT-компиляцию использовать.

Но вот только, какую часть кода нужно скомпилировать заранее, ведь даже разработчики приложений не знают, как именно пользователи будут юзать их программу.

Поэтому в Android 7.0 Nougat Google представили технологию PGC — Profile guided compilation. То есть это компиляция, основанная на профилях использования приложения. Думаю вы уже примерно догадываетесь как эта штука работает.

Естественно от AOT-компиляции на этапе установки отказались. Поэтому во время первого запуска приложения стали снова использовать старую добрую JIT-компиляцию, результат которой, естественно, сохранится в кэш. Тоже самое повторится и во время второго запуска, и третьего. Но когда вы поставите телефон на зарядку и крепко заснете, тогда проснется так называемый «Демон» (это, если что, официальное название специальной службы), который проанализирует кеши всех приложений, которые вы использовали в течение дня. После этого он создаст профили с оптимизированным кодом. И так каждую ночь…

Но и эту проблему Google решили. В Android 9.0 Pie они представили Облачные профили.

Они просто собрали профили приложений со всех пользователей, проанализировали их и создали усредненный профиль для каждого приложения, который теперь стал автоматически скачиваться во время установки приложения из Google Play Store.

Всё это позволило значительно повысить скорость первого запуска приложения, да и в целом, первые дни использования девайса. А, как известно, первое впечатление, второй раз произвести не получится.

И вот мы с вами видим какой огромный путь проделала система Android.

Система стала в десятки раз отзывчивее, оптимизированее и дружелюбнее к пользователям.

Но несмотря на огромное количество изменений под капотом самой системы оставалось одна очень важная проблема: огромное разнообразие устройств. Поэтому переходим к заключительному этапу становления Android.

ЭТАП 4. AAB: Android балансирует

На последнем этапе Google решил уменьшить не только размер скомпилированного кода, но и размер самих приложений.

И в 2018 году они представили новый формат публикаций приложений, который называется Android App Bundle, или просто AAB.

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

Система Android поддерживает 4 архитектуры, 6 разрешений графики и более 150 языков.

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

Поэтому, чтобы разработчики не парились, Google придумал умную систему публикации.

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

А дальше, когда вы заходите в Google Play и скачиваете приложение, то Google Play сам собирает для вас идеальную APK-шку только с необходимым набором данных: подгружается только графика необходимого разрешения, библиотеки только под вашу архитектуру и только тот языковой пакет, который выбран у вас в системе.

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

Тем не менее, последствия от этого нововведения воистину колоссальные. Для Google это позволяет экономить ежедневно 10 ПБ трафика, который тратится на скачку и приложений и обновлений.

А для пользователей это позволят сэкономить просто кучу места на устройстве. Ведь многие приложения похудели более чем на 30 процентов.

Иными словами, от нововведения сплошные блага.

Те кто испугался, что APK больше не будет, это не так. Вы, по-прежнему, сможете скачивать и устанавливать APK-файлы с других источников, тут нет никаких ограничений. Точно также нет ограничений и на сторонние магазины приложений, они также смогут использовать App Bundle или по старинке заставлять разработчиков самим собрать APK. Полная свобода и анархия.

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

Размер приложения Facebook на iOS 246 МБ, на Android — 57. Разница в 4,3 раза!

Instagram. iOS 150 МБ, Android — 39, разница 3.8 раза!

Snapchat 234 против 63 МБ.

TikTok 230 против 67 МБ… и так далее.

В итоге только на выбранном небольшом списке приложений мы получили экономию, более чем в 1 ГБ! Мы считаем — это достойно, именно поэтому Android настоящая народная ОС.

Выводы

Что в итоге. За время своего существования система Android прошла просто огромный путь оптимизации и стала по-настоящему универсальной, быстрой и эффективной системой, которая отлично работает на массе разных устройств. Вот бы все ОС так развивались. (Да, Microsoft?)

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

Источник