Платформа для плагинов для платформы Android gradient

Question

На нашем company мы разрабатываем Android SDK, который содержит как Java, так и родную часть. Мы собираем SDK в формате AAR, который содержит все ресурсы, классы Java и собственные биты. Согласно спецификации AAR, собственные библиотеки должны быть размещены внутри jni-папки внутри пакета AAR. Поскольку текущий плагин gradle не поддерживает расширенные случаи NDK, и поскольку у нас есть очень зрелый файл Android.mk, который развился за 3 года разработки, мы готовим AAR, вызывая собственный сценарий оболочки из задачи градации. Этот сценарий оболочки создает NDK с помощью команды ndk-build, и задача, которая запускает этот скрипт, ставится как зависимость задачи javaCompile (есть несколько вариантов нашего кода, и каждый вкус имеет свои собственные правила для NDK, которые предварительно загружаются из файла определения а затем присваивается ndk-build в качестве аргументов командной строки).

Наконец, когда все скомпилировано, у нас есть задача копирования, которая копирует собственные библиотеки в jni-папку внутри сборки/промежуточных элементов/пакетов (папка, которая в конечном итоге становится заархивированной в AAR). Это работало правильно, пока мы не обновили наш проект, чтобы использовать плагин gradle v1.5.0.

В v1.5.0 в плагин был добавлен что-то, называемое Transform API. Хотя мы не используем это, этот шаг Transform делает некоторое преобразование родных libs в задаче transformNative_libsWithSyncJniLibsForFlavorNameBuildTypeName, который происходит где-то после того, как мы уже скопировали наши библиотеки в jni-папку и вызвали удаление всех данных в jni-папке. Это, в конечном итоге, приводит к тому, что AAR не содержит нативных libs и сбоев, как только требуются собственные методы.

Мы устранили эту проблему, используя project.tasks[taskName], чтобы получить эту задачу и убедиться, что это произойдет до того, как мы скопируем наши библиотеки в папку jni.

Однако проблема в том, что если эта проблема начнет волноваться, если и когда будет установлен экспериментальный плагин с градиентом-экспериментом (единственный, который в настоящее время поддерживает NDK) и станет стандартом для построения кода NDK.

Мы немного экспериментировали с этим экспериментальным плагином и, кроме того, отличались синтаксисом (почему ???), он не поддерживает отладку собственного кода как часть библиотечного модуля (файлы gdb не упакованы в AAR, а флаг jniDebuggable больше не существует) ,

Кто-нибудь знает, когда этот плагин достигнет стабильного API и будет готов к использованию в производственных сборках? Мы планируем заранее перенести нашу миграцию из вызова ndk-build из shellscript в одноразовую конструкцию NDK с градиентом с той же характеристикой (плюс бесплатная поддержка для редактирования C++ из Android Studio, что невозможно в текущей конфигурации, поэтому мы полагаемся на different editor для JNI код клея).

Answer 1

У меня нет дорожной карты, но если вы будете следить за зависимостями, вы увидите, что экспериментальный плагин Android все еще экспериментальный, потому что new Gradle object model все еще экспериментальный. Я ожидаю, что плагин Android Studio не будет стабильным до тех пор, пока базовый код Gradle не станет стабильным.

Это сказало: хотя различия в синтаксисе расстраивают, их обычно довольно легко применять. Что еще более важно, экспериментальный плагин делает, предлагая довольно хорошую поддержку отладки. Он не использует gdb (он использует lldb по умолчанию), и он не полагается на флаг jniDebuggable. Тот факт, что вы ищете, заставляет меня думать, что вы много знаете о том, как работает ndk-gdb, и, возможно, создали свою собственную систему, которая опирается на эти знания. Вы пробовали просто нажать кнопку «Отладка» в Android Studio? Он должен работать нормально, если ваш код на C++ находится в вашем основном проекте. (К сожалению, некоторые проблемы устанавливают точки останова в библиотечных проектах.)