Project import generated by Copybara.
PiperOrigin-RevId: 347612731
Change-Id: I8d91e60fdb757a737b83af111842ef9ec772d735
diff --git a/docs/api_guidelines.md b/docs/api_guidelines.md
index 3781200..aa55d65 100644
--- a/docs/api_guidelines.md
+++ b/docs/api_guidelines.md
@@ -87,7 +87,7 @@
library at the same time and release all libraries at the same time.
Atomic groups are specified in
-[`LibraryGroups.kt`](https://cs.android.com/androidx/platform/frameworks/support/+/androidx-master-dev:buildSrc/src/main/kotlin/androidx/build/LibraryGroups.kt):
+[`LibraryGroups.kt`](https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:buildSrc/src/main/kotlin/androidx/build/LibraryGroups.kt):
```kotlin
// Non-atomic library group
diff --git a/docs/benchmarking.md b/docs/benchmarking.md
index cc38f78..fd66b6e 100644
--- a/docs/benchmarking.md
+++ b/docs/benchmarking.md
@@ -10,7 +10,7 @@
### Writing the benchmark
Benchmarks are just regular instrumentation tests! Just use the
-[`BenchmarkRule`](https://android.googlesource.com/platform/frameworks/support/+/androidx-master-dev/benchmark/junit4/src/main/java/androidx/benchmark/junit4/BenchmarkRule.kt)
+[`BenchmarkRule`](https://android.googlesource.com/platform/frameworks/support/+/androidx-main/benchmark/junit4/src/main/java/androidx/benchmark/junit4/BenchmarkRule.kt)
provided by the library:
<section class="tabs">
@@ -75,16 +75,16 @@
Start by copying one of the following projects:
-* [navigation-benchmark](https://android.googlesource.com/platform/frameworks/support/+/refs/heads/androidx-master-dev/navigation/benchmark/)
-* [recyclerview-benchmark](https://android.googlesource.com/platform/frameworks/support/+/refs/heads/androidx-master-dev/recyclerview/recyclerview-benchmark/)
+* [navigation-benchmark](https://android.googlesource.com/platform/frameworks/support/+/refs/heads/androidx-main/navigation/benchmark/)
+* [recyclerview-benchmark](https://android.googlesource.com/platform/frameworks/support/+/refs/heads/androidx-main/recyclerview/recyclerview-benchmark/)
### Compose
Compose builds the benchmark from source, so usage matches the rest of the
AndroidX project. See existing Compose benchmark projects:
-* [Compose UI benchmarks](https://android.googlesource.com/platform/frameworks/support/+/refs/heads/androidx-master-dev/ui/integration-tests/benchmark/)
-* [Compose Runtime benchmarks](https://android.googlesource.com/platform/frameworks/support/+/refs/heads/androidx-master-dev/compose/compose-runtime/compose-runtime-benchmark/)
+* [Compose UI benchmarks](https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/integration-tests/benchmark/)
+* [Compose Runtime benchmarks](https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/runtime/runtime/compose-runtime-benchmark/)
## Profiling
@@ -106,7 +106,7 @@
```
04:33:49 I/Benchmark: Benchmark report files generated at
-/androidx-master-dev/out/ui/ui/integration-tests/benchmark/build/outputs/connected_android_test_additional_output
+/androidx-main/out/ui/ui/integration-tests/benchmark/build/outputs/connected_android_test_additional_output
```
To inspect the captured trace, open the appropriate `*.trace` file in that
diff --git a/docs/branching.md b/docs/branching.md
index 8b5cd06..074a54c 100644
--- a/docs/branching.md
+++ b/docs/branching.md
@@ -2,21 +2,20 @@
[TOC]
-## Single Development Branch [androidx-master-dev]
+## Single Development Branch [androidx-main]
All feature development occurs in the public AndroidX master dev branch of the
-Android Open Source Project: `androidx-master-dev`. This branch serves as the
-central location and source of truth for all AndroidX library source code. All
-alpha and beta version development, builds, and releases will be done ONLY in
-this branch.
+Android Open Source Project: `androidx-main`. This branch serves as the central
+location and source of truth for all AndroidX library source code. All alpha and
+beta version development, builds, and releases will be done ONLY in this branch.
## Release Branches [androidx-\<feature\>-release]
When a library updates to rc (release-candidate) or stable, that library version
will be snapped over to that library’s release branch. If that release branch
doesn’t exist, then a release branch will be created for that library, snapped
-from androidx-master-dev at the commit that changed the library to an rc or
-stable version.
+from androidx-main at the commit that changed the library to an rc or stable
+version.
Release branches have the following properties:
@@ -27,12 +26,12 @@
* Bug-fixes and updates to that rc or stable version will need to be
individually cherry-picked
* No alpha or beta versions will exist in a release branch.
-* Toolchain and other library wide changes to androidx-master-dev will be
- synced to each release branch.
+* Toolchain and other library wide changes to androidx-main will be synced to
+ each release branch.
* Release branches will have the naming format
`androidx-<feature-name>-release`
-* Release branches will be re-snapped from `androidx-master-dev` for each new
- minor version release (for example, releasing 2.2.0-rc01 after 2.1.0)
+* Release branches will be re-snapped from `androidx-main` for each new minor
+ version release (for example, releasing 2.2.0-rc01 after 2.1.0)
## Platform Developement and AndroidX [androidx-platform-dev]
diff --git a/docs/do_not_mock.md b/docs/do_not_mock.md
index d614001..3dd6531 100644
--- a/docs/do_not_mock.md
+++ b/docs/do_not_mock.md
@@ -1,13 +1,13 @@
-# Do Not Mock, AndroidX
+# Do Not Mock
-All APIs created in AndroidX **must have a testing story**: how developers
-should write tests for their code that relies on a library, this story should
-not be "use mockito to mock class `Foo`". Your goal as API owner is to **create
+All APIs created in Jetpack **must have a testing story**: how developers should
+write tests for their code that relies on a library, this story should not be
+"use Mockito to mock class `Foo`". Your goal as an API owner is to **create
better alternatives** to mocking.
## Why can't I suggest mocks as testing strategy?
-Frequently mocks don't follow guarantees outlined in the API they mock. That
+Frequently, mocks don't follow guarantees outlined in the API they mock. That
leads to:
* Significant difference in the behavior that diminishes test value.
@@ -36,15 +36,15 @@
bundle. But our test passes a mock that don't expect such call and, boom,
test is broken. However, component code is completely valid and has nothing
to do with the broken test. We observed a lot of issues like that during
- updates of android SDK and AndroidX libraries to newer versions internally
- at google. Suggesting to mock our own components is shooting ourselves in
- the foot, it will make adoption of newer version of libraries even slower.
+ updates of Android SDK and Jetpack libraries to newer versions internally at
+ google. Suggesting to mock our own components is shooting ourselves in the
+ foot, it will make adoption of newer version of libraries even slower.
* Messy tests. It always starts with simple mock with one method, but then
this mock grows with the project, and as a result test code has sub-optimal
half-baked class implementation of on top of the mock.
-## But it is ok to mock interfaces, right?
+## But it is okay to mock interfaces, right?
It depends. There are interfaces that don't imply any behavior guarantees and
they are ok to be mocked. However, **not all** interfaces are like that: for
@@ -54,30 +54,24 @@
## What about spying?
-Spying on these classes is banned as well - mockito spies permit stubbing of
+Spying on these classes is banned as well - Mockito spies permit stubbing of
methods just like mocks do, and interaction verification is brittle and
unnecessary for these classes. Rather than verifying an interaction with a
class, developers should observe the result of an interaction - the effect of a
task submitted to an `Executor`, or the presence of a fragment added to your
layout. If an API in your library misses a way to have such checks, you should
-add methods to do that. If you think it is dangerous to open such methods in the
-main surface of your library, consult with
-[API council](https://sites.google.com/corp/google.com/android-api-council), it
-may have seen similar patterns before. For example, one of the possible ways to
-resolve such issue can be adding test artifact with special capabilities. So
-`fragment-testing` module was created to drive lifecycle of Fragment and ease
-interaction with fragments in tests.
+add methods to do that.
-## Avoid mockito in your own tests.
+## Avoid Mockito in your own tests.
One of the things that would help you to identify if your library is testable
-without mockito is not using mockito yourself. Yes, historically we heavily
-relied on mockito ourselves and old tests are not rewritten, but new tests
+without Mockito is not using Mockito yourself. Yes, historically we heavily
+relied on Mockito ourselves and old tests are not rewritten, but new tests
shouldn't follow up that and should take as an example good citizens, for
-example, `-ktx` modules. These modules don't rely on mockito and have concise
+example, `-ktx` modules. These modules don't rely on Mockito and have concise
expressive tests.
-One of the popular and legit patterns for mockito usage were tests that verify
+One of the popular and legit patterns for Mockito usage were tests that verify
that a simple callback-like interface receives correct parameters.
```java
@@ -90,9 +84,9 @@
}
```
-In api like the one above, in java 7 tests for value received in `Callback`
-tended to become very wordy without mockito. But now in your tests you can use
-Kotlin and test will be as short as with mockito:
+In API like the one above, in Java 7 tests for value received in `Callback`
+tended to become very wordy without Mockito. But now in your tests you can use
+Kotlin and test will be as short as with Mockito:
```kotlin
fun test() {
@@ -103,13 +97,13 @@
}
```
-## Don't compromise in API to enable mockito
+## Don't compromise in API to enable Mockito
-Mockito on android
-[had an issue](https://github.com/mockito/mockito/issues/1173) with mocking
-final classes. Moreover, internally at google this feature is disabled even for
-non-android code. So you may hear complaints that some of your classes are not
-mockable, however **It is not a reason for open up a class for extension**. What
+Mockito on Android
+[had an issue](https://github.com/Mockito/Mockito/issues/1173) with mocking
+final classes. Moreover, internally at Google this feature is disabled even for
+non-Android code. So you may hear complaints that some of your classes are not
+mockable, however **it is not a reason for open up a class for extension**. What
you should instead is verify that is possible to write the same test without
mocking, if not, again you should **provide better alternative in your API**.
@@ -119,5 +113,3 @@
showcase for your API, then go to the next step - test that code also. If you
are able to implement tests for your demo app, then users of your API will also
be able to implement tests for functionalities where your API is also used.
-
-## ~~Use @DoNotMock on most of your APIs ~~(Not available yet)
diff --git a/docs/faq.md b/docs/faq.md
index 786cc23..16dca29 100644
--- a/docs/faq.md
+++ b/docs/faq.md
@@ -31,24 +31,25 @@
### Will there be any more updates to Support Library?
No, Revision 28.0.0 of the Support Library, which launched as stable in
-September 2018, was the last feature release in the android.support package.
-There will be no further releases under Support Library packaging.
+September 2018, was the last feature release in the `android.support` package.
+There will be no further releases under Support Library packaging and they
+should be considered deprecated.
-### How is AndroidX related to Jetpack?
+### How are `androidx` and AndroidX related to Jetpack?
-They are the same thing! In a sentence, AndroidX is the packaging and
-internally-facing development project for all components in Jetpack. Jetpack is
-the external branding for libraries within AndroidX.
+They are all the same thing! In a sentence, `androidx` is the packaging and
+AndroidX is the development workflow for all components in Jetpack. Jetpack is
+the external branding for libraries within `androidx`.
In more detail, Jetpack is the external branding for the set of components,
tools, and guidance that improve the developer experience on Android. AndroidX
is the open-source development project that defines the workflow, versioning,
and release policies for ALL libraries included in Jetpack. All libraries within
-the androidx Java package follow a consistent set of API design guidelines,
+the `androidx` Java package follow a consistent set of API design guidelines,
conform to SemVer and alpha/beta revision cycles, and use the Android issue
tracker for bugs and feature requests.
-### What AndroidX library versions have been officially released?
+### What library versions have been officially released?
You can see all publicly released versions on the interactive
[Google Maven page](https://dl.google.com/dl/android/maven2/index.html).
@@ -64,50 +65,6 @@
See the steps specified on the version page
[here](versioning.md#how-to-update-your-version).
-### How do I test my change in a separate Android Studio project?
-
-If you're working on a new feature or bug fix in AndroidX, you may want to test
-your changes against another project to verify that the change makes sense in a
-real-world context or that a bug's specific repro case has been fixed.
-
-If you need to be absolutely sure that your test will exactly emulate the
-developer's experience, you can repeatedly build the AndroidX archive and
-rebuild your application. In this case, you will need to create a local build of
-AndroidX's local Maven repository artifact and install it in your Android SDK
-path.
-
-First, use the `createArchive` Gradle task to generate the local Maven
-repository artifact:
-
-```shell
-# Creates <path-to-checkout>/out/dist/sdk-repo-linux-m2repository-##.zip
-./gradlew createArchive
-```
-
-Next, take the ZIP output from this task and extract the contents to the Android
-SDK path that you are using for your alternate (non-AndroidX) version of Android
-Studio. For example, you may be using `~/Android/SDK/extras` if you are using
-the default Android Studio SDK for app development or
-`prebuilts/fullsdk-linux/extras` if you are using fullsdk for platform
-development.
-
-```shell
-# Creates or overwrites android/m2repository
-cd <path-to-sdk>/extras
-unzip <path-to-checkout>/out/dist/top-of-tree-m2repository-##.zip
-```
-
-Finally, in the dependencies section of your standalone project's `build.gradle`
-file, add or update the `compile` entries to reflect the AndroidX modules that
-you would like to test:
-
-```
-dependencies {
- ...
- compile "com.android.support:appcompat-v7:26.0.0-SNAPSHOT"
-}
-```
-
## Version FAQ {#version}
### How are changes in dependency versions propagated?
@@ -145,27 +102,27 @@
Nope.
-### Can Alpha work (ex. for the next Minor release) occur in the primary development branch during Beta API lockdown?
+### Can alpha work (ex. for the next Minor release) occur in the primary development branch during beta API lockdown?
No. This is by design. Focus should be spent on improving the Beta version and
adding documentation/samples/blog posts for usage!
-### Is there an API freeze window between Alpha and Beta while API surface is reviewed and tests are added, but before the Beta is released?
+### Is there an API freeze window between alpha and beta while API surface is reviewed and tests are added, but before the beta is released?
Yes. If any new APIs are added in this window, the beta release will be blocked
until API review is complete and addressed.
-### How often can a Beta release?
+### How often can a beta release?
As often as needed, however, releases outside of the bi-weekly (every 2 weeks)
release will need to get approval from the TPM (nickanthony@).
-### What are the requirements for moving from Alpha to Beta?
+### What are the requirements for moving from alpha to beta?
-See the [Beta section of Versioning guidelines](versioning.md?#beta) for
+See the [beta section of Versioning guidelines](versioning.md?#beta) for
pre-release cycle transition requirements.
-### What are the requirements for a Beta launch?
+### What are the requirements for a beta launch?
-See the [Beta section of Versioning guidelines](versioning.md?#beta) for
+See the [beta section of Versioning guidelines](versioning.md?#beta) for
pre-release cycle transition requirements.
diff --git a/docs/lint_guide.md b/docs/lint_guide.md
index 5e40600..649eca3 100644
--- a/docs/lint_guide.md
+++ b/docs/lint_guide.md
@@ -105,7 +105,7 @@
`CURRENT_API` is defined by the Lint API version against which your project is
compiled, as defined in the module's `build.gradle` file. Jetpack Lint modules
should compile using Lint API version 3.3 defined in
-[Dependencies.kt](https://cs.android.com/androidx/platform/frameworks/support/+/androidx-master-dev:buildSrc/src/main/kotlin/androidx/build/dependencies/Dependencies.kt;l=176).
+[Dependencies.kt](https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:buildSrc/src/main/kotlin/androidx/build/dependencies/Dependencies.kt;l=176).
We guarantee that our Lint checks work with versions 3.3-3.6 by running our
tests with both versions 3.3 and 3.6. For newer versions of Android Studio (and
@@ -115,7 +115,7 @@
override the `IssueRegistry.getIssues()` method. Here, we override that method
with a Kotlin `get()` property delegate:
-[Example IssueRegistry Implementation](https://cs.android.com/androidx/platform/frameworks/support/+/androidx-master-dev:fragment/fragment-lint/src/main/java/androidx/fragment/lint/FragmentIssueRegistry.kt)
+[Example IssueRegistry Implementation](https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:fragment/fragment-lint/src/main/java/androidx/fragment/lint/FragmentIssueRegistry.kt)
There are 4 primary types of Lint checks:
@@ -132,8 +132,8 @@
To view the PSI structure of any file in Android Studio, use the
[PSI Viewer](https://www.jetbrains.com/help/idea/psi-viewer.html) located in
`Tools > View PSI Structure`. The PSI Viewer should be enabled by default on the
-Android Studio configuration loaded by `studiow` in `androidx-master-dev`. If it
-is not available under `Tools`, you must enable it by adding the line
+Android Studio configuration loaded by `studiow` in `androidx-main`. If it is
+not available under `Tools`, you must enable it by adding the line
`idea.is.internal=true` to `idea.properties.`
<table>
@@ -480,7 +480,7 @@
element, as well as a quick fix. In this case we replace our element text with
some other text.
-[Example Detector Implementation](https://cs.android.com/androidx/platform/frameworks/support/+/androidx-master-dev:fragment/fragment-lint/src/main/java/androidx/fragment/lint/FragmentTagDetector.kt)
+[Example Detector Implementation](https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:fragment/fragment-lint/src/main/java/androidx/fragment/lint/FragmentTagDetector.kt)
### Testing
@@ -533,7 +533,7 @@
If a quick fix was implemented, you can check that the fix is correct by calling
`checkFix()` and providing the expected output file stub.
-[TestExample](https://cs.android.com/androidx/platform/frameworks/support/+/androidx-master-dev:fragment/fragment-lint/src/test/java/androidx/fragment/lint/FragmentTagDetectorTest.kt)
+[TestExample](https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:fragment/fragment-lint/src/test/java/androidx/fragment/lint/FragmentTagDetectorTest.kt)
## Android manifest detector
diff --git a/docs/manual_prebuilts_dance.md b/docs/manual_prebuilts_dance.md
index d06e86f..16762c6 100644
--- a/docs/manual_prebuilts_dance.md
+++ b/docs/manual_prebuilts_dance.md
@@ -14,7 +14,7 @@
repository under `prebuilts/androidx/internal`.
2. Update the version for your library in the public docs configuration
- ([docs-public/build.gradle](https://cs.android.com/androidx/platform/frameworks/support/+/androidx-master-dev:docs-public/build.gradle)).
+ ([docs-public/build.gradle](https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:docs-public/build.gradle)).
If this is the first time that your library is being published, you will
need to add a new entry.
diff --git a/docs/onboarding.md b/docs/onboarding.md
index 5bd331b..6b5251d 100644
--- a/docs/onboarding.md
+++ b/docs/onboarding.md
@@ -91,7 +91,7 @@
Like ChromeOS, Chromium, and the Android build system, we develop in the open as
much as possible. All feature development occurs in the public
-[androidx-master-dev](https://android.googlesource.com/platform/frameworks/support/+/androidx-master-dev)
+[androidx-main](https://android.googlesource.com/platform/frameworks/support/+/androidx-main)
branch of the Android Open Source Project.
As of 2020/03/20, you will need about 38 GB for a fully-built checkout.
@@ -100,17 +100,17 @@
Use the following `repo` commands to check out your branch.
-#### Public master development branch {#source-checkout-master}
+#### Public main development branch {#source-checkout-main}
All development should occur in this branch unless otherwise specified by the
AndroidX Core team.
-The following command will check out the public master development branch:
+The following command will check out the public main development branch:
```shell
-mkdir androidx-master-dev && cd androidx-master-dev
+mkdir androidx-main && cd androidx-main
repo init -u https://android.googlesource.com/platform/manifest \
- -b androidx-master-dev --partial-clone --clone-filter=blob:limit=10M
+ -b androidx-main --partial-clone --clone-filter=blob:limit=10M
repo sync -c -j8
```
@@ -132,7 +132,7 @@
## Explore source code from a browser {#code-search}
-`androidx-master-dev` has a publicly-accessible
+`androidx-main` has a publicly-accessible
[code search](https://cs.android.com/androidx/platform/frameworks/support) that
allows you to explore all of the source code in the repository. Links to this
URL may be shared on public Buganizer and other external sites.
@@ -140,7 +140,7 @@
We recommend setting up a custom search engine in Chrome as a faster (and
publicly-accessible) alternative to `cs/`.
-### Custom search engine for `androidx-master-dev` {#custom-search-engine}
+### Custom search engine for `androidx-main` {#custom-search-engine}
1. Open `chrome://settings/searchEngines`
1. Click the `Add` button
@@ -164,7 +164,7 @@
Studio to work on main set of androidx projects. `ANDROIDX_PROJECTS` has several
other options like `ANDROIDX_PROJECTS=ALL` to open other subsets of the
projects.
-[settings.gradle](https://cs.android.com/androidx/platform/frameworks/support/+/androidx-master-dev:settings.gradle)
+[settings.gradle](https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:settings.gradle)
file in the repository has these options listed.
```shell
@@ -320,13 +320,12 @@
task:
```
-./gradlew disttipOfTreeDocs
+./gradlew doclavaDocs
```
-This will output docs in the zip file:
-`{androidx-master-dev}/out/dist/android-support-tipOfTree-docs-0.zip`, as well
-as in local html files that you can check from your browser:
-`{androidx-master-dev}/out/androidx/build/javadoc/tipOfTree/offline/reference/packages.html`
+To generate offline docs use '-PofflineDocs=true' parameter. Places the
+documentation in
+`{androidx-main}/out/dist/out/androidx/docs-tip-of-tree/build/javadoc`
#### KotlinDocs
@@ -334,11 +333,11 @@
task:
```
-./gradlew distTipOfTreeDokkaDocs
+./gradlew dokkaKotlinDocs
```
-This will output docs in the zip file:
-`{androidx-master-dev}/out/dist/dokkaTipOfTreeDocs-0.zip`
+Places the documentation in
+`{androidx-main}/out/dist/out/androidx/docs-tip-of-tree/build/dokkaKotlinDocs`
#### Release docs
@@ -346,15 +345,15 @@
[d.android.com](http://d.android.com), run the Gradle command:
```
-./gradlew distpublicDocs
+./gradlew zipDoclavaDocs
```
This will create the artifact
-`{androidx-master-dev}/out/dist/android-support-public-docs-0.zip`. This command
-builds docs based on the version specified in
-`{androidx-master-dev-checkout}/frameworks/support/buildSrc/src/main/kotlin/androidx/build/PublishDocsRules.kt`
+`{androidx-main}/out/dist/doclava-public-docs-0.zip`. This command builds docs
+based on the version specified in
+`{androidx-main-checkout}/frameworks/support/buildSrc/src/main/kotlin/androidx/build/PublishDocsRules.kt`
and uses the prebuilt checked into
-`{androidx-master-dev-checkout}/prebuilts/androidx/internal/androidx/`. We
+`{androidx-main-checkout}/prebuilts/androidx/internal/androidx/`. We
colloquially refer to this two step process of (1) updating PublishDocsRules.kt
and (2) checking in a prebuilt artifact into the prebuilts directory as
[The Prebuilts Dance](releasing.md#the-prebuilts-dance™). So, to build javadocs
@@ -366,11 +365,10 @@
difference being that we use the Gradle command:
```
-./gradlew distPublicDokkaDocs
+./gradlew zipDokkaDocs
```
-which generates the kotlin docs artifact
-`{androidx-master-dev}/out/dist/dokkaPublicDocs-0.zip`
+This will create the artifact `{androidx-main}/out/dist/dokka-public-docs-0.zip`
### Updating public APIs {#updating-public-apis}
@@ -409,8 +407,7 @@
the semi-optional commit tag `Relnote:` in your commit, which will automatically
include that message the commit in the pre-populated release notes.
-The presence of a `Relnote:` tag is required for API changes in
-`androidx-master-dev`.
+The presence of a `Relnote:` tag is required for API changes in `androidx-main`.
#### How to use it?
@@ -517,7 +514,7 @@
topic) with the dependent library code.
Libraries typically reference dependencies using constants defined in
-[`Dependencies.kt`](https://cs.android.com/androidx/platform/frameworks/support/+/androidx-master-dev:buildSrc/src/main/kotlin/androidx/build/dependencies/Dependencies.kt),
+[`Dependencies.kt`](https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:buildSrc/src/main/kotlin/androidx/build/dependencies/Dependencies.kt),
so please update this file to include a constant for the version of the library
that you have checked in. You will reference this constant in your library's
`build.gradle` dependencies.
@@ -632,7 +629,7 @@
### Obtaining a build ID
To browse build IDs, you can visit either
-[androidx-master-dev](https://ci.android.com/builds/branches/aosp-androidx-master-dev/grid?)
+[androidx-main](https://ci.android.com/builds/branches/aosp-androidx-main/grid?)
on ci.android.com or [Snapshots](https://androidx.dev/snapshots/builds) on the
androidx.dev site.
@@ -655,14 +652,14 @@
```
```shell
-ID=`curl -s "https://ci.android.com/builds/branches/aosp-androidx-master-dev/status.json" | jq ".targets[] | select(.ID==\"aosp-androidx-master-dev.androidx_snapshot\") | .last_known_good_build"` \
+ID=`curl -s "https://ci.android.com/builds/branches/aosp-androidx-main/status.json" | jq ".targets[] | select(.ID==\"aosp-androidx-main.androidx_snapshot\") | .last_known_good_build"` \
&& echo https://ci.android.com/builds/submitted/"${ID:1:-1}"/androidx_snapshot/latest/raw/repository/
```
#### Android build server
Go to
-[androidx-master-dev](https://ci.android.com/builds/branches/aosp-androidx-master-dev/grid?)
+[androidx-main](https://ci.android.com/builds/branches/aosp-androidx-main/grid?)
on ci.android.com.
For `androidx-snapshot` target, wait for the green "last known good build"
diff --git a/docs/policies.md b/docs/policies.md
index b099299..1cf4502 100644
--- a/docs/policies.md
+++ b/docs/policies.md
@@ -67,13 +67,13 @@
specified in the artifact directory's `OWNERS` file.
Artifact versions are specified in
-[`LibraryVersions.kt`](https://cs.android.com/androidx/platform/frameworks/support/+/androidx-master-dev:buildSrc/src/main/kotlin/androidx/build/LibraryVersions.kt).
+[`LibraryVersions.kt`](https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:buildSrc/src/main/kotlin/androidx/build/LibraryVersions.kt).
Versions are bound to your artifact in the `supportLibrary` block in your
artifact's `build.gradle` file. The `Version` class validates the version string
at build time.
In the
-[`LibraryVersions.kt`](https://cs.android.com/androidx/platform/frameworks/support/+/androidx-master-dev:buildSrc/src/main/kotlin/androidx/build/LibraryVersions.kt)
+[`LibraryVersions.kt`](https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:buildSrc/src/main/kotlin/androidx/build/LibraryVersions.kt)
file:
```
diff --git a/docs/testing.md b/docs/testing.md
index b937bb9..21be773 100644
--- a/docs/testing.md
+++ b/docs/testing.md
@@ -14,9 +14,9 @@
[aosp/1189799](https://android-review.googlesource.com/c/platform/frameworks/support/+/1189799).
For an example of how to set up Espresso-powered integration tests, see the
`preference` library's
-[`build.gradle`](https://cs.android.com/androidx/platform/frameworks/support/+/androidx-master-dev:preference/preference/build.gradle)
+[`build.gradle`](https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:preference/preference/build.gradle)
and
-[`EditTextPreferenceTest.java`](https://cs.android.com/androidx/platform/frameworks/support/+/androidx-master-dev:preference/preference/src/androidTest/java/androidx/preference/tests/EditTextPreferenceTest.java)
+[`EditTextPreferenceTest.java`](https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:preference/preference/src/androidTest/java/androidx/preference/tests/EditTextPreferenceTest.java)
files.
The currently allowed test runners for on-device tests are
@@ -27,7 +27,7 @@
### What gets tested, and when
We use the
-[AffectedModuleDetector](https://cs.android.com/androidx/platform/frameworks/support/+/androidx-master-dev:buildSrc/src/main/kotlin/androidx/build/dependencyTracker/AffectedModuleDetector.kt)
+[AffectedModuleDetector](https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:buildSrc/src/main/kotlin/androidx/build/dependencyTracker/AffectedModuleDetector.kt)
to determine what projects have changed since the last merge.
In presubmit, "affected" modules will run all host and device tests regardless
@@ -122,7 +122,7 @@
In rare cases, like testing the animations themselves, you may want to enable
animations for a particular test or test class. For those cases, you can use the
-[`AnimationDurationScaleRule`](https://cs.android.com/androidx/platform/frameworks/support/+/androidx-master-dev:testutils/testutils-runtime/src/main/java/androidx/testutils/AnimationDurationScaleRule.kt).
+[`AnimationDurationScaleRule`](https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:testutils/testutils-runtime/src/main/java/androidx/testutils/AnimationDurationScaleRule.kt).
## Using the emulator {#emulator}
@@ -185,11 +185,15 @@
Following a successful build, tests may be run against a particular AndroidX
module using `gradlew`.
-To run all integration tests in a specific project, run the following from
-`framework/support`:
+To run all unit or integration tests in a specific project, run the following
+from `framework/support`:
```shell
-./gradlew <project-name>:connectedCheck --info --daemon
+# Run instrumentation tests on a connected device
+./gradlew <project-name>:connectedAndroidTest --info --daemon
+
+# Run local unit tests
+./gradlew <project-name>:test --info --daemon
```
substituting the Gradle project name (ex. `core`).
@@ -198,14 +202,14 @@
working on, run
```shell
-./gradlew <project-name>:connectedCheck --info --daemon \
+./gradlew <project-name>:connectedAndroidTest --info --daemon \
-Pandroid.testInstrumentationRunnerArguments.class=<fully-qualified-class>[\#testName]
```
substituting the Gradle project name (ex. `viewpager`) and fully-qualified class
name (ex. `androidx.viewpager.widget.ViewPagerTest`) of your test file,
optionally followed by `\#testName` if you want to execute a single test in that
-file.
+file. Substitute `test` for `connectedAndroidTest` to run local unit tests.
If you see some weird compilation errors such as below, run `./gradlew clean`
first:
diff --git a/docs/truth_guide.md b/docs/truth_guide.md
index fd9efc4..494f4b9 100644
--- a/docs/truth_guide.md
+++ b/docs/truth_guide.md
@@ -122,7 +122,7 @@
```
To test that expected failure cases you should use the
-[assertThrows](https://cs.android.com/androidx/platform/frameworks/support/+/androidx-master-dev:testutils/testutils-truth/src/main/java/androidx/testutils/assertions.kt)
+[assertThrows](https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:testutils/testutils-truth/src/main/java/androidx/testutils/assertions.kt)
function from the AndroidX testutils module. The assertions.kt file contains two
assertThrows functions. The second method, which specifically returns a
TruthFailureSubject, should be used since it allows for validating additional
diff --git a/docs/versioning.md b/docs/versioning.md
index f1212a3..16c7498 100644
--- a/docs/versioning.md
+++ b/docs/versioning.md
@@ -261,9 +261,9 @@
A few notes about version updates:
-- The version of your library listed in `androidx-master-dev` should *always*
- be higher than the version publically available on Google Maven. This allows
- us to do proper version tracking and API tracking.
+- The version of your library listed in `androidx-main` should *always* be
+ higher than the version publically available on Google Maven. This allows us
+ to do proper version tracking and API tracking.
- Version increments must be done before the CL cutoff date (aka the build cut
date).
@@ -276,11 +276,11 @@
[How to update your version on a release branch](release_branches.md#update-your-version)
- When you're ready for `rc01`, the increment to `rc01` should be done in
- `androidx-master-dev` and then your release branch should be snapped to that
+ `androidx-main` and then your release branch should be snapped to that
build. See the guide [Snap your release branch](release_branches.md#snap) on
how to do this. After the release branch is snapped to that build, you will
- need to update your version in `androidx-master-dev` to `alpha01` of the
- next minor (or major) version.
+ need to update your version in `androidx-main` to `alpha01` of the next
+ minor (or major) version.
### Bi-weekly batched releases (every 2 weeks)
