Разница между compile files и provided files c точки зрения разработчика библиотеки

#android #android_library

Я создал простою библиотеку (AAR), которая при вызове функции взаимодействует с приложением
через механизм бродкастов. И вот у меня возник вопрос: как правильно подключать её
сторонним разработчикам через compile files и provided files и могу ли я на это как-то
повлиять? 

Насколько я понял из немногочисленной информации в интернете, если ее подключать
через compile files, то она включается в APK, а если через provided files, то зависимость
происходит на этапе компиляции. Я не совсем понимаю плюсы/минусы каждого подхода и
как я могу на это повлиять в качестве разработчика?! 

У меня был случай, когда я подключил стороннюю библиотеку через compile files вместо
provided files и при вызове некоторых функций получал ошибку сигментации. Я не хочу,
чтобы такая ситуация случилась с моей библиотекой и поэтому хочу подробнее разобраться
в проблеме.
    

Ответы

Ответ 1

Для подключения зависимостей в Gradle есть несколько конфигураций:


implementation (compile до Gradle plugin 3.0)
Самая часто используемая, добавляет при компиляции зависимость в classpath текущего
модуля и добавляет в APK (для модулей с типом "приложение")
api (compile до Gradle plugin 3.0)
Добавляет при компиляции зависимость в classpath текущего модуля и всех, кто использует
его, также добавляет в APK (для модулей с типом "приложение"). Данную конфигурацию
обычно используют в модулях библиотек для заявления транзитивных зависимостей.
compileOnly (provided до Gradle plugin 3.0)
Добавляет при компиляции зависимость в classpath текущего модуля и НЕ добавляет в
APK (для модулей с типом "приложение"). Например, вы используете библиотеку, которая
опциональна и/или поставляется производителем устройства. 
runtimeOnly (apk до Gradle plugin 3.0)
Добавляет зависимость в APK, но НЕ добавляет при компиляции зависимость в classpath
текущего модуля


Т.к. вы разработчик библиотеки, то вам следует уделить внимание использованию implementation
и api для зависимостей вашей библиотеки.

Если библиотека используется в модуле приложения, то она подключается всегда через
implementation (исключение - библиотеки, являющиеся частью Андроида на конкретном устройстве)

Android Library различия -source и -javadocs артефактов

#android #gradle #android_library #javadoc

Написал библиотеку, выложил в jcenter, подцепил и заметил алерт который меня напрягает:



Ни в одной библиотеке, которую я использовал до этого не было такого алерта, следовательно
- я где-то накосячил в таске формирования -source и -javadocs артефактов.

Может кто сталкивался с этим до меня?

Скрипт формирования артефактов:

android.libraryVariants.all { variant ->
    def javadocTask = task("generate${variant.name.capitalize()}Javadoc", type: Javadoc) {
        description "Generates Javadoc for $variant.name."
        source = variant.javaCompile.source
        ext.androidJar = project.files(android.getBootClasspath().join(File.pathSeparator))
        classpath = files(variant.javaCompile.classpath.files) + files(ext.androidJar)
        exclude '**/BuildConfig.java'
        exclude '**/R.java'
    }

    javadocTask.dependsOn variant.javaCompile

    def jarJavadocTask = task("jar${variant.name.capitalize()}Javadoc", type: Jar) {
        description "Generate Javadoc Jar for $variant.name"
        classifier = 'javadoc'
        from javadocTask.destinationDir
    }

    jarJavadocTask.dependsOn javadocTask
    artifacts.add('archives', jarJavadocTask)

    def jarSourceTask = task("jar${variant.name.capitalize()}Sources", type: Jar) {
        description "Generates Java Sources for $variant.name."
        classifier = 'sources'
        from variant.javaCompile.source
    }

    jarSourceTask.dependsOn variant.javaCompile
    artifacts.add('archives', jarSourceTask)
}


Сама библиотека: https://bintray.com/ztrap-llc/maven/FormattedEditText/
    

Ответы

Ответ 1

Разобрался (правда не без пары вырванных клоков волос). Косяк действительно допустил
я. Но узнать в каком именно месте, мне не удалось, т.к. на просторе GitHub'ов я позаимствовал
скрипт, который (О, чудо!) идеально отработал.

Ниже сам скрипт:

task androidJavadocs(type: Javadoc) {
    source = android.sourceSets.main.java.srcDirs
    classpath += project.files(android.getBootClasspath().join(File.pathSeparator))
    classpath += configurations.compile
}

task androidJavadocsJar(type: Jar, dependsOn: androidJavadocs) {
    classifier = 'javadoc'
    from androidJavadocs.destinationDir
}

task androidSourcesJar(type: Jar) {
    classifier = 'sources'
    from android.sourceSets.main.java.sourceFiles
}

artifacts {
    archives androidSourcesJar
    archives androidJavadocsJar
}

Разница использования библиотек поддержки?

#java #android #lib #android_support_library #android_library

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

Я так понял, что в зависимости для какого апи пишешь то такую библиотеку и нужно
использовать. 

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

android.support.v4
android.support.v13


Я так понимаю, что 

android.support.v4


Можно вовсе удалить так как 

android.support.v13


должна включать в себя все из предыдущей библиотеки, верно я понял?
    

Ответы

Ответ 1

К сожалению все неправильно.

Во первых, версией библиотеки считается трехзначный номер в конце (как 24.3.0), а
не число, что идет после v. в названии библиотеки. Эти числа - это до какого минимального
API эта библиотека поддержки собственно оказывает поддержку. Так, v.4 значит, что библиотека
поддержки будет работать на устройствах с API4 и выше.

Использовать нужно версию библиотеки не менее чем minSDKversion проекта и равную
или более, чем compileSDKversion (targetSDKversion) а крайне  желательно - последнюю
стабильную (сейчас это 24.3.0), так как с каждой новой версией вносятся фиксы в существующие
классы и дополняются новые классы или методы. При этом смотреть соответствие API нужно
по мажорному номеру библиотеки (здесь 24.3.0 - для compileSDKversion API24).  

Ознакомиться с изменениями, вносимыми в библиотеки поддержки с каждой новой ревизией
можно на официальном сайте разработчика Android - здесь указано, какие именно изменения
и дополнения были внесены с каждой ревизией и в какие именно из библиотек поддержки
(так в ревизии 24.3.0 были внесены изменения в библиотеки v4, v7 (в подбиблиотеки AppCompat,
MediaRouter, Preferences, RecyclerView) , Design.

библиотеки support.v4 , support.v7 и тд - это разные библиотеки, с различными классами
поддержки и выполняемыми функциями и они не взаимозаменяют друг друга по принципу большей
версии. С полным списком библиотек поддержки Google и их назначением и функциями вы
можете ознакомиться на все том же официальном сайте разработчика Android.

Например, библиотека com.android.support:support-v4:24.3.0 - библиотека поддержки
с минимальным API, на котором она работает API4 и версией самой библиотеки - 24.3.0.
Список классов и функций этой библиотеки можно посмотреть здесь. Как видите, это совсем
не то же, что библиотека com.android.support:support-v7, в которую входит вообще несколько
отдельных библиотек, как ApppCompat, CardView и тд.

PS: никакой библиотеки support.v21 у Google не наблюдается ..

Как редактировать код в загруженных библиотеках?

#java #android #gradle #android_library

Здравствуйте, я загрузил библиотеку

compile 'com.daimajia.slider:library:1.1.5@aar'

и в ней есть баг, мне надо его пофиксить. Но я не могу вносить правки в проект, он
закрыт для редактирования.



Пожалуйста помогите!
    

Ответы

Ответ 1

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

Если вы используете у себя в проекте систему контроля версий git, то легче всего
подключить библиотеку как подмодуль. Для этого: 


В командной строке переходите в коталог со своим проектом;
Выполняете команду git submodule add git://github.com/path_to_lib;
В корневом файле settings.gradle добавляете ее так include ':libName';
В build.gradle модуля приложения добавляете так compile project(':LibName:library').


После этого вы можете вносить изменения в библиотеку, которые потом будут отображены
в вашем проекте. После чего вы легко сможете отправить pull request автору библиотеки
с фиксом бага. 

Про то, как работать с подмодулями в гит, и как они себе ведут при коммите прочтите
на официальном сайте(ссылка выше).


Ответ 2

Вбейте в гугл пакет библиотеки.
По первой ссылке перейдите на страницу либы на GitHub-e
Скачайте библиотеку как набор исходных файлов в архиве.
Распакуйте архив.
Откройте код в IDE
Отредактируйте.
Соберите *.jar файл библиотеки (опционально)
Подключите исправленную версию библиотеки или с помощью файла из п.7 или добавьте
проект с библиотекой в виде зависимости.


Ответ 3

Вы не можете изменять уже собранные библиотеки (строго говоря можете, но это плохой
и сложный путь). Вы можете либо отнаследоваться от проблемного класса, исправить поведение
в наследнике и использовать его если косяк не слишком глубокий. Либо если это open
source библиотека форкуть её, исправить и либо отправить пулл реквест с исправлением
автору оригинальной библиотеки что бы он включил его в свой репозиторий и обновил библиотеку,
либо собрать свою реализацию и использовать её в своём проекте.


Ответ 4

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

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

Создание библиотеки. Как предоставить возможность ее использовать

Здравствуйте. Написал библиотеку с анимациями, своими классами, методами и т.д. Хочу её выложить на гитхаб. Что нужно сделать чтобы разработчик мог добавить её к себе в проект? Ну, тоесть добавить в dependencies, подключить и использовать? На данный момент она представлена в виде проекта, компилируемая в apk. Делаю впервые, поэтому не понимаю. Вопрос, наверное, детский :D

Ответ

Вам нужно опубликовать библиотеку в какой-нибудь публичный репозиторий. Посмотрите тут: https://inthecheesefactory.com/blog/how-to-upload-library-to-jcenter-maven-central-as-dependency/en

Использование @hide в javadoc

Не раз встречался с аннотацией @hide в Javadoc. Известно что эта аннотация запрещает доступ к методу после релиза (доступ всё так же можно получить через рефлексию).
У меня появилась необходимость объявить интерфейс публичным для доступа из другого package, но при этом не дать возможность его использовать конечному пользователю. Есть ли какая нибудь возможность воспользоваться этой аннотацией или аналогом с подобным функционалом?
Исходя из ответа, это реализовать невозможно, но так как ответ был дан в 2014 году, есть надежда, что положение дел изменилось.

Ответ

Вы неправильно понимаете @hide. На ваш код @hide не оказывает никакого влияния вообще (как до релиза, так и после - чтобы это не значило в вашем вопросе). @hide используется только при генерации android.jar - библиотеки с заглушками.
Что касается проблемы видимости:
Скрыть публичный интерфейс нельзя. Возможно, получится все реализации интерфейса перенести в тот же пакет что и сам интерфейс. Это решит проблему видимости. Можно оставить видимость package и везде где нужен экземпляр класса использовать рефлексию Class.forName(...) Если у вас есть доступ к процессу компиляции, то можно для написания кода использовать "нерабочую" jar с заглушками, а в момент компиляции подменять на полноценный jar со всеми файлами.
P.S. Публичный интерфейс это даже хорошо. Вдруг кому-то понадобится написать его собственную реализацию данного интерфейса.

Пояснения к пункту 4 :
Если вы делаете публичную библиотеку, то хотите чтобы сторонние программисты видели только некоторые функции и класс, или хотите скрыть реализацию функций и ресурсы и т.д.. С помощью public/private/protected скрыть всё что вы хотите невозможно. Поэтому иногда используют метод под названием stub.jar он же dummy code. Этот метод является основой подхода "Skeleton programming".
Заключается он в том, что в проект стороннего программиста вместо вашей библиотеки добавляется stub.jar - это библиотека из которой вырезана реализация методов, ресурсы, скрытые классы и методы - всё то, что сторонний программист не должен видеть. Такой jar можно написать самому или сгенерировать чем-нибудь типа Stubber. Кончено такой jar неработоспособен - там только заглушки.
Зачем это нужно - сторонний программист не видит ваши скрытые классы, алгоритмы шифрования и т.д., но при этом он может писать, компилировать, и тестировать свой код так как-будто использует вашу библиотеку.
Чтобы получить готовый продукт нужно перед компиляцией подменить stub.jar на рабочую библиотеку. Как это сделать зависит от вашей системы сборки. Можно подменять руками - удалять старый jar и добавлять новый, можно использовать системы сборки типа Gradle например так:
task replaceStubs() { delete fileTree(dir: 'libs' , include: '**/*_Stub.jar') copy { from `MyRelaseLibsFolder` into `libs` } }
P.P.S. Есть субъективное ощущение что это не то что вам нужно

Разница между compile files и provided files c точки зрения разработчика библиотеки

Я создал простою библиотеку (AAR), которая при вызове функции взаимодействует с приложением через механизм бродкастов. И вот у меня возник вопрос: как правильно подключать её сторонним разработчикам через compile files и provided files и могу ли я на это как-то повлиять?
Насколько я понял из немногочисленной информации в интернете, если ее подключать через compile files, то она включается в APK, а если через provided files, то зависимость происходит на этапе компиляции. Я не совсем понимаю плюсы/минусы каждого подхода и как я могу на это повлиять в качестве разработчика?!
У меня был случай, когда я подключил стороннюю библиотеку через compile files вместо provided files и при вызове некоторых функций получал ошибку сигментации. Я не хочу, чтобы такая ситуация случилась с моей библиотекой и поэтому хочу подробнее разобраться в проблеме.

Ответ

Для подключения зависимостей в Gradle есть несколько конфигураций:
implementation (compile до Gradle plugin 3.0) Самая часто используемая, добавляет при компиляции зависимость в classpath текущего модуля и добавляет в APK (для модулей с типом "приложение") api (compile до Gradle plugin 3.0) Добавляет при компиляции зависимость в classpath текущего модуля и всех, кто использует его, также добавляет в APK (для модулей с типом "приложение"). Данную конфигурацию обычно используют в модулях библиотек для заявления транзитивных зависимостей. compileOnly (provided до Gradle plugin 3.0) Добавляет при компиляции зависимость в classpath текущего модуля и НЕ добавляет в APK (для модулей с типом "приложение"). Например, вы используете библиотеку, которая опциональна и/или поставляется производителем устройства. runtimeOnly (apk до Gradle plugin 3.0) Добавляет зависимость в APK, но НЕ добавляет при компиляции зависимость в classpath текущего модуля
Т.к. вы разработчик библиотеки, то вам следует уделить внимание использованию implementation и api для зависимостей вашей библиотеки.
Если библиотека используется в модуле приложения, то она подключается всегда через implementation (исключение - библиотеки, являющиеся частью Андроида на конкретном устройстве)

Android Library различия -source и -javadocs артефактов

Написал библиотеку, выложил в jcenter, подцепил и заметил алерт который меня напрягает:

Ни в одной библиотеке, которую я использовал до этого не было такого алерта, следовательно - я где-то накосячил в таске формирования -source и -javadocs артефактов.
Может кто сталкивался с этим до меня?
Скрипт формирования артефактов:
android.libraryVariants.all { variant -> def javadocTask = task("generate${variant.name.capitalize()}Javadoc", type: Javadoc) { description "Generates Javadoc for $variant.name." source = variant.javaCompile.source ext.androidJar = project.files(android.getBootClasspath().join(File.pathSeparator)) classpath = files(variant.javaCompile.classpath.files) + files(ext.androidJar) exclude '**/BuildConfig.java' exclude '**/R.java' }
javadocTask.dependsOn variant.javaCompile
def jarJavadocTask = task("jar${variant.name.capitalize()}Javadoc", type: Jar) { description "Generate Javadoc Jar for $variant.name" classifier = 'javadoc' from javadocTask.destinationDir }
jarJavadocTask.dependsOn javadocTask artifacts.add('archives', jarJavadocTask)
def jarSourceTask = task("jar${variant.name.capitalize()}Sources", type: Jar) { description "Generates Java Sources for $variant.name." classifier = 'sources' from variant.javaCompile.source }
jarSourceTask.dependsOn variant.javaCompile artifacts.add('archives', jarSourceTask) }
Сама библиотека: https://bintray.com/ztrap-llc/maven/FormattedEditText/

Ответ

Разобрался (правда не без пары вырванных клоков волос). Косяк действительно допустил я. Но узнать в каком именно месте, мне не удалось, т.к. на просторе GitHub'ов я позаимствовал скрипт, который (О, чудо!) идеально отработал.
Ниже сам скрипт:
task androidJavadocs(type: Javadoc) { source = android.sourceSets.main.java.srcDirs classpath += project.files(android.getBootClasspath().join(File.pathSeparator)) classpath += configurations.compile }
task androidJavadocsJar(type: Jar, dependsOn: androidJavadocs) { classifier = 'javadoc' from androidJavadocs.destinationDir }
task androidSourcesJar(type: Jar) { classifier = 'sources' from android.sourceSets.main.java.sourceFiles }
artifacts { archives androidSourcesJar archives androidJavadocsJar }

Разница использования библиотек поддержки?

При чтении статей сталкиваюсь с тем, что пишут нужно подключить такую или такую библиотеку поддержки. Я немного почитал, чтоб постараться от сего зависит какую библиотеку нужно подключать.
Я так понял, что в зависимости для какого апи пишешь то такую библиотеку и нужно использовать.
Я открыл один из своих проектов и в градле заметил, что у меня бывает даже есть 2 библиотеки разных версий. Допустим так
android.support.v4 android.support.v13
Я так понимаю, что
android.support.v4
Можно вовсе удалить так как
android.support.v13
должна включать в себя все из предыдущей библиотеки, верно я понял?

Ответ

К сожалению все неправильно.
Во первых, версией библиотеки считается трехзначный номер в конце (как 24.3.0), а не число, что идет после v. в названии библиотеки. Эти числа - это до какого минимального API эта библиотека поддержки собственно оказывает поддержку. Так, v.4 значит, что библиотека поддержки будет работать на устройствах с API4 и выше.
Использовать нужно версию библиотеки не менее чем minSDKversion проекта и равную или более, чем compileSDKversion (targetSDKversion) а крайне желательно - последнюю стабильную (сейчас это 24.3.0), так как с каждой новой версией вносятся фиксы в существующие классы и дополняются новые классы или методы. При этом смотреть соответствие API нужно по мажорному номеру библиотеки (здесь 24.3.0 - для compileSDKversion API24).
Ознакомиться с изменениями, вносимыми в библиотеки поддержки с каждой новой ревизией можно на официальном сайте разработчика Android - здесь указано, какие именно изменения и дополнения были внесены с каждой ревизией и в какие именно из библиотек поддержки (так в ревизии 24.3.0 были внесены изменения в библиотеки v4, v7 (в подбиблиотеки AppCompat, MediaRouter, Preferences, RecyclerView) , Design
библиотеки support.v4 , support.v7 и тд - это разные библиотеки, с различными классами поддержки и выполняемыми функциями и они не взаимозаменяют друг друга по принципу большей версии. С полным списком библиотек поддержки Google и их назначением и функциями вы можете ознакомиться на все том же официальном сайте разработчика Android.
Например, библиотека com.android.support:support-v4:24.3.0 - библиотека поддержки с минимальным API, на котором она работает API4 и версией самой библиотеки - 24.3.0. Список классов и функций этой библиотеки можно посмотреть здесь. Как видите, это совсем не то же, что библиотека com.android.support:support-v7, в которую входит вообще несколько отдельных библиотек, как ApppCompat, CardView и тд.
PS: никакой библиотеки support.v21 у Google не наблюдается ..