commit | 9ff667a9247b52cac5667ef10dcbbc703ab2cee6 | [log] [tgz] |
---|---|---|
author | Oussama Ben Abdelbaki <[email protected]> | Fri Jan 11 10:17:59 2019 -0500 |
committer | Oussama Ben Abdelbaki <[email protected]> | Fri Jan 11 10:20:45 2019 -0500 |
tree | 886c6e35451d19c4e127904c5b076e40bc4598a1 | |
parent | 7b5a3a6a5641b61279d39de0ac782990d403ea7f [diff] |
Fixed broken min/max testing Lazy evaluation caused maxDepVersions tasks to not switch dependencies due to module:project map not being complete. Due to test application ids being similar for all flavors (apparently an AGP bug), minDepVersions and maxDepVersions tests could not be ran simultaneously on a device, which is also a problem. The following CL forces evaluation of all children before dependency substitution and substitutes for the debug variant (cannot substitute for release variant after evaluation.) Removed flavors completely to make the build faster since it makes more sense to test binary compatibility during presubmits/postsubmits. We now use a flag (-PuseMaxDepVersions) instead which triggers substitution. Only debug configurations/tasks are substituted for, which is fine since buildOnServer, buildTestApks build using debug tasks. Lint also runs on the debug variant so this works for our purposes (although it is currently disabled for maxdepversions as I am investigating some behavior.) The plan is to run presubmit and postsubmit targets twice with every second target running with the -PuseMaxDepVersions flag. This parallelizes runs and guarantees binary compatibility testing while still running in theoratically the same time as before flavors (although we are likely to use more resources.) Test: ./gradlew <project>:dependencies -PuseMaxDepVersions Observe the dependencies change to project dependencies in debug configurations. (compared to a run without the flag.) Also deprecate a method in ToT and make sure that using the flag on a project depending on a released artifact of the project containing the deprecated class show a warning about using deprecated class meaning it did indeed switch to the ToT version of that dependency. (introducing an error is also another method of testing, although I personally have not tried it this time.) Change-Id: Ic9c7a3c5844cda20f1d7e0acd6cf856b6fe035c1
We are not currently accepting new modules.
NOTE: You will need to use Linux or Mac OS. Building under Windows is not currently supported.
Follow the “Downloading the Source” guide to install and set up repo
tool, but instead of running the listed repo
commands to initialize the repository, run the folowing:
repo init -u https://android.googlesource.com/platform/manifest -b androidx-master-dev
The first time you initialize the repository, it will ask for user name and email.
Now your repository is set to pull only what you need for building and running AndroidX libraries. Download the code (and grab a coffee while we pull down 3GB):
repo sync -j8 -c
You will use this command to sync your checkout in the future - it’s similar to git fetch
Open path/to/checkout/frameworks/support/
in Android Studio. Now you're ready edit, run, and test!
If you get “Unregistered VCS root detected” click “Add root” to enable git integration for Android Studio.
If you see any warnings (red underlines) run Build > Clean Project
.
You can do most of your work from Android Studio, however you can also build the full AndroidX library from command line:
cd path/to/checkout/frameworks/support/ ./gradlew createArchive
You can build maven artifacts locally, and test them directly in your app:
./gradlew createArchive
And put in your project build.gradle
file:
handler.maven { url '/path/to/checkout/out/host/gradle/frameworks/support/build/support_repo' }
Run FooBarTest
Run androidx.foobar
The AndroidX repository has a set of Android applications that exercise AndroidX code. These applications can be useful when you want to debug a real running application, or reproduce a problem interactively, before writing test code.
These applications are named either <libraryname>-integration-tests-testapp
, or support-\*-demos
(e.g. support-4v-demos
or support-leanback-demos
). You can run them by clicking Run > Run ...
and choosing the desired application.
Before uploading your first contribution, you will need setup a password and agree to the contribution agreement:
Generate a HTTPS password: https://android-review.googlesource.com/new-password
Agree to the Google Contributor Licenses Agreement: https://android-review.googlesource.com/settings/new-agreement
cd path/to/checkout/frameworks/support/ repo start my_branch_name . (make needed modifications) git commit -a repo upload --current-branch .
If you see the following prompt, choose always
:
Run hook scripts from https://android.googlesource.com/platform/manifest (yes/always/NO)?
If the upload succeeds, you'll see output like:
remote: remote: New Changes: remote: https://android-review.googlesource.com/c/platform/frameworks/support/+/720062 Further README updates remote:
To edit your change, use git commit --amend
, and re-upload.
AndroidX uses git to store all the binary Gradle dependencies. They are stored in prebuilts/androidx/internal
and prebuilts/androidx/external
directories in your checkout. All the dependencies in these directories are also available from google()
, jcenter()
, or mavenCentral()
. We store copies of these dependencies to have hermetic builds. You can pull in a new dependency using our importMaven tool.