План экспериментальных плагинов для 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 клеевого кода).

4

Решение

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

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

1

Другие решения

Других решений пока нет …

По вопросам рекламы [email protected]