Невозможно опубликовать пакет приложений из-за требований 64-разрядной версии Google Play
Я сталкиваюсь с постоянной 64-битной ошибкой при попытке опубликовать обновление App Bundle моего приложения Android в Google Play.
Техническая установка:
- Тип проекта: Стандартный проект Kotlin для Android.
- Версия инструментов сборки Android: 34.0.0
- minSdkВерсия: 24
- компиляцияSdkVersion: 34
- цельSdkVersion: 33
- Версия плагина Android Gradle: 8.4.1
- Версия Android Gradle Wrapper: gradle-8.6-bin.zip
Контекст:
- Я тщательно следил за официальной документацией Google по публикации App Bundle, особенно в отношении требований к 64-битной библиотеке.
- Я создаю App Bundle со следующей задачей Gradle
bundleRelease. - Мой проект успешно работает в 64-битном симуляторе внутри моей IDE.
- С помощью команды file я проверил, что три собственные библиотеки в папке «lib» пакета приложений действительно имеют 64-разрядную версию (архитектуры Arm64-v8a и x86_64).
- Я подтверждаю, что не использую Unity или какой-либо Native Development Kit (NDK).
- RenderScript не используется.
- Я безуспешно пытался
ndk.abiFilters 'armeabi-v7a','arm64-v8a','x86','x86_64'. - Я читал другие сообщения SO, такие как это, но безуспешно.
Я связался со службой поддержки Google Play, но они не смогли решить проблему и закрыли заявку, заявив, что не могут дать более конкретный ответ. Будем очень признательны за любые идеи или предложения по решению этой проблемы.
Да, сделал это, как уже упоминалось в пункте о трех собственных библиотеках, с помощью file cmd. Хотя все в порядке. В любом случае спасибо за совет.
Моя рекомендация была нацелена на все файлы, включенные в aab, а не только на те, которые, как вы знаете, являются 64-битными файлами .so.
Как выглядят каталоги вашей родной библиотеки? (Т.е. какие файлы находятся в lib/ рекурсивно?)
@Pierre У меня есть три собственных файла в этих папках: armeabi-v7a, x86, arm64-v8a и x86_64. Как уже упоминалось, я позаботился о том, чтобы каждый файл соответствовал своей архитектуре. Я обновил дело, добавив новый ответ, который для меня не имеет никакого смысла.
Привет @Pierre, ребята, у вас есть идеи, почему это может быть причиной такого поведения? Мы сходили с ума, пока не выяснили эту уникальную разницу между работающими и нерабочими версиями, но смысла не видим. Однако алгоритм Google Play это отвергает.
Да, в этом нет особого смысла, и трудно поверить, что это единственная разница... Вы случайно не можете поделиться со мной AAB?
Знаю, я так же думал и лично все проверял и тестировал сам. Наш CI/CD полностью детерминирован: он полностью изолирован, воспроизводим и не допускает изменчивости. Конечно, я могу предоставить вам эти два AAB с уникальным кодом различия между ними. Как я мог связаться с тобой?
Поделиться ссылкой на Диск и предоставить мне доступ по запросу? Или как пожелаете.
Причину нашли... расследование было нетривиальным, но тем не менее весёлым!
Ответы 2
Хотите верьте, хотите нет, но после долгого упражнения «разделяй и властвуй», сравнивая текущую версию с прежней 64-битной версией, я обнаружил следующее:
ПРИМЕЧАНИЕ. Код максимально упрощен.
App Bundle A – совместимость с 64-разрядной версией Google Play
// Invoked from MainApplication
val deviceInfo = AndroidUtils.addDeviceInformationHeader()
println(deviceInfo)
}
object AndroidUtils {
@JvmStatic
fun addDeviceInformationHeader(): String {
return StringBuilder().toString()
}
}
Пакет приложений B – НЕсовместим с 64-разрядной версией Google Play
// Invoked from MainApplication
// val deviceInfo = AndroidUtils.addDeviceInformationHeader()
// println(deviceInfo)
}
object AndroidUtils {
@JvmStatic
fun addDeviceInformationHeader(): String {
return StringBuilder().toString()
}
}
Больше ничего в проекте не меняется от App Bundle A до B. Вообще ничего. Оба пакета приложений A и B были созданы в одной и той же среде на основе Docker. Каждая сборка начинается с пустой проверки, содержащей только разницу в коде, которую вы видите в A и B. Сама сборка выполняет задачу bundleRelease Gradle.
Хотя причина остается неясной, я рад поделиться дополнительной информацией с Google, если они помогут улучшить ясность и точность своих 64-битных проверок соответствия.
Android автоматически считает любой APK работающим только в 32-битной среде, если он содержит файл с расширением «.bc» (RenderScript). Это описано здесь: https://developer.android.com/games/ оптимизировать/64-бит#renderscript-and-64-bit
Кажется, вы используете обфускатор, который меняет имена некоторых файлов. Один из файлов в каталоге META-INF/ не имеет расширения, но имя файла было переименовано в com.package.name.Bc <- Android (и, следовательно, Play) подумал, что это файл RenderScript из-за кажущегося расширения «.bc», и поэтому пометил AAB считается 32-битным независимо от доступных собственных библиотек.
Повторный запуск обфускатора после комментирования одной строки кода привел к другому случайному имени файла com.package.name.Cc, поэтому сработал другой AAB.
Конечно, было бы полезно отладить, если бы в сообщении об ошибке была указана причина, по которой оно несовместимо с 64-разрядными версиями... :/
Господи Иисусе... Я просматривал правила снова и снова и безуспешно обменивался электронными письмами со службой поддержки Google, и, наконец, это было все, хе-хе. Это было сложно, но, хотя и вводит в заблуждение, теперь это имеет смысл. Эта разница вообще не имела никакого смысла. Возможно, добавление проверки нижнего регистра и неопределенной проверки подписи биткода RenderScript поможет устранить большинство этих проблем. Большое спасибо за помощь, Пьер.
Да, к сожалению, этот корабль уже давно отплыл, когда кто-то представил код в кодовой базе Android, проверяя только суффикс .bc, и релиз вышел в свет. После этого пути назад уже нет, поскольку всегда будут устройства с работающим этим кодом... Я посмотрю, можно ли улучшить сообщение об ошибке в Play Console.
Ах да, я имел в виду добавление этих проверок в Play Console, чтобы в большинстве случаев даже не появлялось сообщений об ошибках, что сводит к минимуму ложные срабатывания. Например, у меня не возникнет никакой ошибки, потому что заглавная буква «.B» или подпись бит-кода относятся к RS.
Я не знаю, какие проверки выполняет Google, чтобы определить, что ваше приложение содержит 32-битный код. Одной из простых мер было бы использовать пакет aab, который вы загрузили в Google, и извлечь его в новую папку. Затем выполните команду Linux
fileдля каждого извлеченного файла. Отфильтруйте все файлы, идентифицированные как файлы ELF, и проверьте, имеют ли они размер 32 (arm-v7) или 64 (arm-v8a).