| commit | 1cd0e4eb391fb7e7d5ac60433f705496a9390384 | [log] [tgz] |
|---|---|---|
| author | Sumir Kataria <sumir@google.com> | Tue Dec 12 10:53:46 2017 -0800 |
| committer | Sumir Kataria <sumir@google.com> | Tue Dec 12 14:07:38 2017 -0800 |
| tree | 64698f2a6919a56eb0c13e9290d57cb0ddc101d4 | |
| parent | ab24109bcabf0fa7de14013728c4667f4083278b [diff] |
Make Work/PeriodicWork respectful of top-level package.
Currently, BaseWork has some stuff that the developer cares
about but it sits in the impl subpackage. This is a large
refactor that cleans up a lot of the weirdness with our
file layout.
- Removed BaseWork entirely
- PeriodicWork and Work no longer share a base class;
there was no real reason they needed to
- All constants moved to Constants.java
- Moved the BaseWork.Builder to a new class of its own
and made it an interface (because it shouldn't know
about WorkSpecs, etc.)
- Made Work and PeriodicWork abstract, with abstract
Builders (again, they shouldn't know about WorkSpecs
and other implementation details)
- Both classes have newBuilder methods that will
instantiate concrete implementations; these in turn
go to WorkManager (more on this below)
- The impl package contains concrete implementations of
Work and PeriodicWork, backed by WorkSpecs
- Note that these classes can no longer share a
parent (this was causing all the confusion in
ag/3346205) so there is some code duplication; I
chose not to make a helper object for this
- WorkManager contains protected abstract methods to
create Work and PeriodicWork builders that are backed
by concrete implementations in WorkManagerImpl
- This allows us to have only one exposed impl object
(WorkManagerImpl in WorkManager.getInstance())
- Updated tests; a lot like the previously mentioned CL
Test: updated tests
Change-Id: Ic66f4637d6246085be09b9e8709f7d9a710f770a
We are not currently accepting new modules, features, or behavior changes.
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 ub-supportlib-master
Now your repository is set to pull only what you need for building and running support library. Download the code (and grab a coffee while we pull down 7GB):
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 support library from command line:
cd path/to/checkout/frameworks/support/ ./gradlew createArchive
Run FooBarTestRun android.support.foobarSupport library has a set of Android applications that exercise support library 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 support-*-demos (e.g. support-4v-demos or support-leanback-demos. You can run them by clicking Run > Run ... and choosing the desired application.
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)?