This CL fixes the following compiler warnings.

- Indirect access to static member
- Access to a non-accessible member of an enclosing type
- Parameter assignment
- Method can be static
- Local variable declaration hides another field or variable
- Value of local variable is not used
- Unused import
- Unused private member
- Unnecessary 'else' statement
- Unnecessary declaration of throw exception
- Redundant type arguments
- Missing '@Override' annotation
- Unused '@SuppressWarning' annotations

Bug: 18003991
Change-Id: Icfebe753e53a2cc621848f769d6a3d7ce501ebc7

There are many ways to fix this problem but this is the most
direct way. Removing a view from the cache when any animation
is started will ensure it won't be used again, and will be garbage
collected when it's possible. Since views are created on demand
anyway, a new one will just get created when needed, and that's
it.

Bug: 9400128
Change-Id: I4945d2859d642e79694d51ae90cf4f5bde9a5f1d

The default implementation for preferences refuses to
cache the views for custom preferences at all. We can
do it, but the system won't do it for us, so this does it.
This makes the screen scrolling smooth again.

Incidentally it also fixes the bug where the button may
not animate on the first element.

Bug: 8882722
Bug: 8883108
Change-Id: I9b2306ac4bf93761a808ebfee3477a65f017cddf

Clicking on a button that is animating-out is only done by
mistake. Better make them unclickable.
Also, interrupt an out-in animation if it has been preempted.

Bug: 7600384
Change-Id: Ic4700cda46a894ea580bc67ee7bef885ecf1d3bc

Bug: 7600384
Change-Id: If5efb9357075193d10255187008e870e2933bdb8

Bug: 7600384
Change-Id: I8009b31d96646acd667db410b94e969daea91d52

Handling buttons directly in the preference causes large
problems of code readability and interface.  It's better to
have a class to manage the buttons and their animations
separately. This is feature-equivalent, and mostly
delegates stuff for now.

Bug: 7600384
Change-Id: Ia8da0ec68ffac84fc1d65e1760539a87a73fa776