ライブラリをアップロードする
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
ライブラリへのアクセスを許可するには、リポジトリを選択する必要があります。このページでは、リポジトリ タイプの選択に関する考慮事項と、Maven Publish プラグインを使用してパブリケーションを作成する方法について説明します。
ライブラリをアップロードする前に、リリース用のライブラリを準備し、必要なパブリケーション バリアントやテスト フィクスチャを構成してください。
リポジトリ タイプを選択する
ライブラリは AAR ファイルとして公開されます。このファイルには、バイトコードとネイティブ ライブラリとしてコンパイルされたコード、Android マニフェスト、リソースが含まれています。パッケージ自体は、ID、バージョン、他のライブラリへの依存関係を宣言しません。
通常、AAR を直接配布するのではなく、リポジトリ経由で AAR を提供することをおすすめします。この方法では、ユーザーはライブラリの提供元をより簡単に把握できます(バージョンなどの重要な詳細情報がない name.aar
ファイルを処理する手間を省くことができます)。新しいバージョンのライブラリにアップグレードする場合は、リポジトリを使用すると、新しいバージョンの必須の依存関係のみが追加されるため、ユーザーは手動で依存関係を更新せずに済みます。
リポジトリを使用してライブラリを公開する方法には、次のような複数のメリットがあります。
- Gradle は、ライブラリの依存関係を依存関係グラフに自動的に追加できます。
- Gradle は、依存関係グラフにライブラリの単一のバージョンが含まれることを保証し、それによってライブラリが異なるバージョンで推移的に複数回インクルードされる場合の競合を解決します。
- Android Gradle プラグイン(AGP)は、より効率的な脱糖を行うことで(ライブラリで Java 8 以上の言語機能を使用している場合)、ユーザーのためにビルド時間を短縮できます。
- ライブラリでバリアントの公開を使用し、テスト フィクスチャなどの機能を含めることができます。
AAR を直接配布する場合、ライブラリの ID、バージョン、依存関係に関する情報はユーザーに提供されません。リポジトリに公開する場合、配布はリポジトリ メカニズムに含まれる別のファイルによって処理されます。これは、Maven リポジトリの場合は POM ファイルです。したがって、AAR ファイルを手動で配布するのではなく、リポジトリを使用してライブラリを公開することを強くおすすめします。
リポジトリのタイプ
リポジトリには次の 3 つのタイプがあります。
- Maven Central などの無料のオンライン リポジトリ。誰でもライブラリをアップロードでき、ダウンロードできます。
- 非公開リポジトリ。ログインを介してアクセスが行われるので、非公開ライブラリの配布を管理できます。
- フォルダベースのローカル リポジトリ。手動ダウンロードを介してライブラリを配布できます。
フォルダベースのローカル リポジトリを使用する方法は、ユーザーに AAR への手動ダウンロード リンクを提供する方法や、メールで AAR を送信する方法とよく似ています。主な違いは、AAR のみを送信するのではなく、ID、バージョン、依存関係に関する追加情報も送信する点です。
AAR とメタデータを含むフォルダベースのリポジトリの ZIP ファイルを配布します。ユーザーはファイルを解凍して中身をプロジェクトに追加し、Gradle で参照できます。それ以降は、あたかもライブラリがオンライン リポジトリに存在するかのように、Maven 座標を使用してライブラリへの依存関係を宣言し、上記のメリットをすべて利用できます。
パブリケーションを作成する
Gradle Maven Publish プラグインを使用して公開します。Maven Publish プラグインにより、パブリケーションとリポジトリを宣言でき、それらのパブリケーションをリポジトリに公開するタスクが作成されます。これらのパブリケーションは、ビルドを駆動するプラグインが作成する SoftwareComponent
インスタンス(AGP または java-library
プラグイン)を消費します。
なお、AGP を使用して Maven Publish プラグインを実行する場合、プラグインが適用されたときにソフトウェア コンポーネントが直接作成されるわけではありません。代わりに
作成された
afterEvaluate()
コールバックステップによって行われます。したがって、ソフトウェア コンポーネントを選択するパブリケーションも afterEvaluate()
ステップで構成する必要があります。
次に示すモジュール レベルの build.gradle
ファイルのコード スニペットは、singleVariant()
または multipleVariants()
で作成された特定のバリアントのパブリケーションを作成します。
Groovy
publishing {
publications {
release(MavenPublication) {
groupId = 'com.my-company'
artifactId = 'my-library'
version = '1.0'
afterEvaluate {
from components.release
}
}
}
}
Kotlin
publishing {
publications {
register<MavenPublication>("release") {
groupId = "com.my-company"
artifactId = "my-library"
version = "1.0"
afterEvaluate {
from(components["release"])
}
}
}
}
上記の例では、コンポーネントの名前(components.release
)は、singleVariant()
または multipleVariants()
のいずれかに付けられた名前に基づいています。
パブリケーションを宣言したら、ターゲット リポジトリを作成する必要があります。
ローカル リポジトリに公開する
ローカル リポジトリへの公開は、リポジトリの宣言を除けば、リモート リポジトリへの公開とよく似ています。リモート リポジトリに公開する方法について前のセクションを参照し、目的のバリアント(1 つまたは複数)を公開するパブリケーションを作成します。その後、ローカル リポジトリを作成します。
Groovy
publishing {
publications {
release(MavenPublication) {
...
}
}
repositories {
maven {
name = 'myrepo'
url = layout.buildDirectory.dir("repo")
}
}
}
Kotlin
publishing {
publications {
register<MavenPublication>("release") {
...
}
}
repositories {
maven {
name = "myrepo"
url = uri(layout.buildDirectory.dir("repo"))
}
}
}
これにより、publishReleaseToMyRepoRepository
というタスクが作成されます。この名前は、パブリケーションの名前とリポジトリの名前で構成されます。このタスクを実行すると、指定した場所にリポジトリが生成されます。この例では、プロジェクトのビルドフォルダ内(repo
ディレクトリの下)にリポジトリが生成されます。
リポジトリの ZIP ファイルを自動的に生成させる場合は、次のコードを使用します。
Groovy
tasks.register('generateRepo', Zip) {
def publishTask = tasks.named('publishReleasePublicationToMyrepoRepository')
from publishTask.map { it.getRepository().getUrl() }
into 'mylibrary'
archiveFileName.set('mylibrary.zip')
}
Kotlin
tasks.register<Zip>("generateRepo") {
val publishTask = tasks.named(
"publishReleasePublicationToMyrepoRepository",
PublishToMavenRepository::class.java)
from(publishTask.map { it.repository.url })
into("mylibrary")
archiveFileName.set("mylibrary.zip")
}
このコードは、generateRepo
という Zip
タスクを作成します。このタスクは、公開タスクの内容を消費して圧縮するとともに、ZIP エントリを mylibrary
という最上位フォルダに配置します。出力は build/distributions
に配置されます。
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。Java および OpenJDK は Oracle および関連会社の商標または登録商標です。
最終更新日 2025-07-27 UTC。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["必要な情報がない","missingTheInformationINeed","thumb-down"],["複雑すぎる / 手順が多すぎる","tooComplicatedTooManySteps","thumb-down"],["最新ではない","outOfDate","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["サンプル / コードに問題がある","samplesCodeIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-07-27 UTC。"],[],[],null,["# Upload your library\n\nTo grant access to your library, you need to choose a repository.\nThis page guides you through the considerations related to choosing a\nrepository type and shows how to create a publication using the\n[Maven Publish Plugin](https://docs.gradle.org/current/userguide/publishing_maven.html).\n\nBefore uploading your library, make sure you have [prepared your library for\nrelease](/studio/publish-library/prep-lib-release) and configured any necessary\n[publication variants](/studio/publish-library/configure-pub-variants) or\n[test fixtures](/studio/publish-library/configure-test-fixtures).\n\nChoose a repository type\n------------------------\n\nLibraries are published as AAR files. These files contain compiled code as\nbytecode and native libraries, an Android manifest, and resources. The package\nitself does not declare any identity, version, or dependencies on other\nlibraries.\n\nProviding AARs through a repository is generally the best practice, rather\nthan distributing the AAR directly. It\nhelps users have a better understanding of where the library is coming from\nrather than having to deal with a `name.aar` file without important details,\nlike version. When upgrading to a newer version of a library, use a\nrepository to ensure that only the required dependencies of the newer version\nare added, so that users don't have to manually update dependencies.\n\nThere are multiple benefits to using a repository to publish your library:\n\n- Gradle can automatically add your library's dependencies to the [dependency\n graph](https://docs.gradle.org/current/userguide/viewing_debugging_dependencies.html).\n- Gradle can ensure that a single version of your library is in the dependency graph, resolving conflicts if your library is transitively included more than once with different versions.\n- The Android Gradle Plugin (AGP) can do more efficient desugaring if your library uses Java 8 or higher language features, reducing build times for your users.\n- Your library can use variant publishing and include features like test fixtures.\n\nDistributing the AAR directly doesn't provide your user with any information\nregarding the identity, version, or dependencies of your library. When\npublishing to a repository, distribution is handled by a separate file that is\npart of the repository mechanism. For Maven repositories, this is the\n[POM file](https://maven.apache.org/guides/introduction/introduction-to-the-pom.html). Therefore, it is strongly recommended to publish libraries using\nrepositories rather than manually distributing AAR files.\n\n### Types of repositories\n\nThere are three types of repositories:\n\n- Free online repositories, like Maven Central, let anyone upload and download libraries.\n- Private repositories, with access via login, allow controlled distribution of private libraries.\n- Local, folder-based repositories allow distribution of libraries through manual download.\n\nUsing local, folder-based repositories is very similar to providing your users\nwith a manual download link to the AAR or sending the AAR by email. The main\ndifference is that you are not sending just the AAR but also the additional\ninformation about identity, version, and dependencies.\n\nYou distribute a zip file of the folder-based repository containing your AAR\nplus the metadata. Your users can then extract the file's contents, add the\ncontents to their project, and point Gradle to it. From then on, the users can\ndeclare a dependency on the library using Maven coordinates, as if the library\nwere in an online repository, and benefit from all the advantages mentioned\nearlier.\n\nCreate the publication\n----------------------\n\nPublish using the [Gradle Maven Publish Plugin](https://docs.gradle.org/current/userguide/publishing_maven.html). The Maven Publish Plugin lets you declare publications and\nrepositories and creates tasks to publish these publications to the\nrepositories. These publications consume a `SoftwareComponent` instance that\nthe plugin that drives the build creates, which could be AGP or the\n`java-library` plugin.\n\nNote that when running the Maven Publish Plugin with AGP, the software\ncomponents are not created directly when the plugin is applied. They are instead\ncreated during the\n[`afterEvaluate()`](https://docs.gradle.org/current/userguide/build_lifecycle.html)\ncallback step. Therefore, the publication that selects the software component\nmust also be configured during the `afterEvaluate()` step.\n\nThe following code snippet of the module-level `build.gradle` file creates a\npublication for a given variant created with `singleVariant()` or\n`multipleVariants()`: \n\n### Groovy\n\n```groovy\npublishing {\n publications {\n release(MavenPublication) {\n groupId = 'com.my-company'\n artifactId = 'my-library'\n version = '1.0'\n\n afterEvaluate {\n from components.release\n }\n }\n }\n}\n```\n\n### Kotlin\n\n```kotlin\npublishing {\n publications {\n register\u003cMavenPublication\u003e(\"release\") {\n groupId = \"com.my-company\"\n artifactId = \"my-library\"\n version = \"1.0\"\n\n afterEvaluate {\n from(components[\"release\"])\n }\n }\n }\n}\n```\n\nIn the preceding example, the name of the component (`components.release`) is\nbased on the name that was given to either `singleVariant()`\nor `multipleVariants()`.\n\nOnce you declare a publication, you must create a target repository.\n\n### Publish to a local repository\n\nPublishing to a local repository is very similar to publishing to a remote\nrepository, except for the repository declaration. Read the preceding section to\nlearn how to [publish to a remote repository](#create-pub) to create a\npublication that publishes the desired variant or variants. Then create a local\nrepository: \n\n### Groovy\n\n```groovy\npublishing {\n publications {\n release(MavenPublication) {\n ...\n }\n }\n repositories {\n maven {\n name = 'myrepo'\n url = layout.buildDirectory.dir(\"repo\")\n }\n }\n}\n```\n\n### Kotlin\n\n```kotlin\npublishing {\n publications {\n register\u003cMavenPublication\u003e(\"release\") {\n ...\n }\n }\n repositories {\n maven {\n name = \"myrepo\"\n url = uri(layout.buildDirectory.dir(\"repo\"))\n }\n }\n}\n```\n\nThis creates a task called\n`publish`**Release** `To`**MyRepo**`Repository` that consists of\nthe name of the publication and the name of the repository. Run this task\nto generate the repository to the location provided. In this example, the\nrepository is generated inside the build\nfolder of the project, under a `repo` directory.\n\nIf you want to automatically generate a zip file of the repository, do\nso using the following code: \n\n### Groovy\n\n```groovy\ntasks.register('generateRepo', Zip) {\n def publishTask = tasks.named('publishReleasePublicationToMyrepoRepository')\n from publishTask.map { it.getRepository().getUrl() }\n into 'mylibrary'\n archiveFileName.set('mylibrary.zip')\n}\n```\n\n### Kotlin\n\n```kotlin\ntasks.register\u003cZip\u003e(\"generateRepo\") {\n val publishTask = tasks.named(\n \"publishReleasePublicationToMyrepoRepository\",\n PublishToMavenRepository::class.java)\n from(publishTask.map { it.repository.url })\n into(\"mylibrary\")\n archiveFileName.set(\"mylibrary.zip\")\n}\n```\n\nThis code creates a `Zip` task called `generateRepo` that consumes the content\nof the publishing task and compresses it while ensuring that the zip entries are in a\ntop-level folder called `mylibrary`. The output is located under\n`build/distributions`."]]