План экспериментальных плагинов для Android gradle

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

Наконец, когда все скомпилировано, у нас есть задача «Копировать», которая копирует собственные библиотеки в папку jni внутри build / middleates / bundles (папка, которая в итоге архивируется в AAR). Это работало правильно, пока мы не обновили наш проект, чтобы использовать плагин Gradle v1.5.0.

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

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

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

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

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