| commit | df64f2ab05e32519d95adc1625cdd840f650956c | [log] [tgz] |
|---|---|---|
| author | Tor Norbye <tnorbye@google.com> | Thu Nov 16 14:50:47 2017 -0800 |
| committer | Aurimas Liutikas <aurimas@google.com> | Tue Dec 12 23:24:36 2017 +0000 |
| tree | d1944d6f089277a7f818981a88ef61fe7216d7e6 | |
| parent | e1df7598df29c02e66a17a5c0fa54fb5cb64b2ec [diff] |
Switch @IntDef from long to int, and add @LongDef
The @IntDef annotation actually uses a *long* to store the set
of expected constants. This was to avoid having to have
separate annotations for int- and long-constants.
This works well in Java since int's are silently upconverted
to longs.
However, in retrospect, that was a very bad idea. In Kotlin,
there's no such silent upconversion; referencing an int constant
in an @IntDef does not compile. It insists you explicitly call
toLong() on each constant -- which not only is ugly, but doesn't
even compile in an annotation.
This means @IntDef is completely broken for Kotlin.
This CL fixes this by switching the value type back to int, and
introducing a @LongDef annotation for the rare cases where the
constants being listed are actually longs.
Note that this is an incompatible change: code which was
referencing long constants from an @IntDef will no longer
compile. However, this is really rare:
- frameworks/base has nearly 400 IntDef annotations and only a
handful of them longs.
- frameworks/support has ~125 IntDef annotations and only 2 of
them were using longs.
The developer experience after upgrading to a new version if
using long constants is an error message from the compiler like
this:
PlaybackStateCompat.java:48: error: incompatible types: possible lossy
conversion from long to int
@IntDef(flag=true, value={ACTION_STOP, ACTION_PAUSE, ACTION_...
Test: These annotations have source retention so there is no
runtime impact. The test is the compiler.
Change-Id: If888e4f5e629655a095dfbfb77e2e92c5c31b382
(cherry picked from commit 77795c65aa61622895e12f3266051d6e5df12440)
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)?