1. Graphics & Animation in Android

2. Android rendering options
The Canvas API
Renderscript
OpenGL wrappers
NDK OpenGL

3. The Canvas API
Standard rendering for a typical SDK application that uses View objects (standard and custom)
consists of calls to each View's onDraw() method. This method takes a single parameter, Canvas, which is the object used by the view to draw its content.
and performs and rendering by calling the various methods in the Canvas class
For example, a Button might tell its background Drawable to draw itself into the Canvas and then draw its label with a call to Canvas.drawText()

4. Renderscript Introduced in Android 3.0
API targeted  high-performance 3D rendering and compute operations
a 3D rendering API on top of hardware acceleration, language C99
executing native code on the device still cross-platform
use of extensions that are placed into the application package
When the app is run, the scripts are compiled to machine code and optimized on the device. This eliminates the problem of needing to target a specific machine architecture during the development process.

5. Renderscript
Live Wallpapers, the video wall view in the YouTube application, and the Books application (including that beautiful page-turn effect).
The video above, captured through an Android tablet’s HDMI out, is an example of Renderscript compute at work. (There’s ahigh-def version on YouTube.) In the video we show a simple brute force physics simulation of around 900 particles. The compute script runs each frame and automatically takes advantage of both cores. Once the physics simulation is done, a second graphics script does the rendering. In the video we push one of the larger balls to show the interaction. Then we tilt the tablet and let gravity do a little work. This shows the power of the dual A9s in the new Honeycomb tablet.

6. Open GL Wrappers OpenGL APIs at the SDK level
not a recommended practice as a general approach for complex scenes that require high-performance graphics
difficult to achieve high performance levels equivalent to native access to OpenGL due to the overhead of calling down from the SDK
Music application that shipped with Android 3.0 used this approach
That is, you can write an application using the SDK, with full access to usual SDK APIs and functionality, and still use OpenGL ES 1.x and OpenGL ES 2.0 APIs, by calling the wrapper functions in GLES10 or GLES20 classes. These wrappers call the underlying OpenGL APIs at the native level for those versions of OpenGL ES.
For casually exploring or using OpenGL, this may be a reasonable option. But while this approach works, it's not a recommended practice as a general approach for complex scenes that require high-performance graphics. For one thing, it is difficult to achieve high performance levels equivalent to native access to OpenGL due to the overhead of calling down from the SDK to the native level for every OpenGL call.
The Music application that shipped with Android 3.0 used this approach. The application was an SDK application which needed some simple 3D graphics operations, such as the carousel view of albums. The main reason that it uses the SDK/OpenGL approach is because it is an unbundled application (not dependent upon a particular release of the SDK) and needed to work on releases back to 2.2. It therefore used APIs that were available on those previous releases.

7. NDK OpenGL
no access to the View objects, or the events, or the rest of the infrastructure that is provided in the SDK APIs
graphics environment sufficient for some specific purposes: game developers
compiles applications to specific CPU architectures
The NDK exists to provide an easy porting layer for existing applications written in native code, or which use native libraries. Porting might be more easily and quickly accomplished by using the NDK than by converting existing code to the language and APIs used by the SDK.
The NDK does not provide the rich GUI toolkit of the Android platform at the native level, so developers do not have access to the View objects, or the events, or the rest of the infrastructure that is provided in the SDK APIs. But there is a graphics environment at the NDK level that is sufficient for some specific purposes. In particular, game developers that simply want a fullscreen game experience can find what they need with OpenGL. This API provides low-level graphics functionality that lets applications display 2D and 3D graphics using the GPU for maximum graphics performance.
One important restriction of the NDK to keep in mind is that it compiles applications to specific CPU architectures. This means that if you only build your application for one specific chip, then the application will not work on Android devices that do not have that chip architecture. This is particularly important in the broad and growing Android ecosystem where new devices are coming out all the time. You probably want your application to work as well on new chips as it did on the ones you used to develop the application. So while the NDK OpenGL solution provides a reasonable route to fast graphics performance, it does so at the cost of the portability that other solutions offer.
One of the questions that came up about Renderscript when I talked to developers was how to access it from the NDK. This is not currently possible. Renderscript is specifically created to be a companion to SDK applications. We envision users of Renderscript as SDK applications that use Renderscript for their high-performance graphics or computation needs. These applications might be primarily SDK applications, with GUIs and interaction and most other facilities provided by the SDK APIs and small but important pieces of functionality provided by Renderscript, such as graphics effects that would otherwise not be possible or not perform as well. Or these applications might use Renderscript for most of what they do, just using the SDK to initialize the scripts and letting Renderscript take over from there.

8. Animations Animations prior to Android 3.0 android.view.animation
move, scale, rotate, and fade Views
combine multiple animations together in an AnimationSet
specify animations in a LayoutAnimationController to get automatically staggered animation 
use Interpolator implementations like AccelerateInterpolator and Bounce to get natural, nonlinear timing behavior

9. Animations Animations prior to Android 3.0
you can animate Views... and that's it
How to animate the position of a Drawable in a custom drawing? Or translucency?
you can move, rotate, scale, and fade a View... and that's it.
animating the background color of a View?
hard-coded set of things they were able to do, and you could not make them do anything else.
For one thing, you can animate Views... and that's it. To a great extent, that's okay.
The GUI objects in Android are, after all, Views. So as long as you want to move a Button, or a TextView, or a LinearLayout, or any other GUI object, the animations have you covered. But what if you have some custom drawing in your view that you'd like to animate, like the position of a Drawable, or the translucency of its background color? Then you're on your own, because the previous animation system only understands how to manipulate View objects.

10. Animations Animations in Android 3.0
not specific to Views
animates values over time
assigning those values to any target objects and properties
And you can move a Drawable inside a View. And you can animate the background color of a Drawable. In fact, you can animate the values of anydata structure; you just tell the animation system how long to run for, how to evaluate between values of a custom type, and what values to animate between, and the system handles the details of calculating the animated values and setting them on the target object.

11. Animations
Animator
superclass for classes which provide basic support for animations which can be started, ended, and have AnimatorListeners added to them
java.lang.Object
   ↳
android.animation.Animator
android.animation.AnimatorSet
The listeners tend to be important, because sometimes you want to key some action off of the end of an animation, such as removing a view after an animation fading it out is done. asic support for animations which can be started, ended, and have AnimatorListeners added to them
AnimatorListener
java.lang.Object
  ↳
android.animation.Animator
android.animation.ValueAnimator
android.animation.ObjectAnimator

12. Animations AnimatorSet
 choreograph multiple animators together into a single animation
 animations can be set up to play together, in sequence, or after a specified delay
“It is possible to set up a AnimatorSet with circular dependencies between its animations… results of this configuration are undefined… circular dependencies should be avoided”
superclass for classes which provide b
It is possible to set up a AnimatorSet with circular dependencies between its animations. For example, an animation a1 could be set up to start before animation a2, a2 before a3, and a3 before a1. The results of this configuration are undefined, but will typically result in none of the affected animations being played. Because of this (and because circular dependencies do not make logical sense anyway), circular dependencies should be avoided, and the dependency flow of animations should only be in one direction

13. Animations ValueAnimator
 runs the internal timing loop that causes all of a process's animations to calculate and set values
 two pieces to animating properties: calculating the animated values and setting those values on the object and property in question. ValueAnimator takes care of the first part; calculating the values
superclass for classes which provide b
It is possible to set up a AnimatorSet with circular dependencies between its animations. For example, an animation a1 could be set up to start before animation a2, a2 before a3, and a3 before a1. The results of this configuration are undefined, but will typically result in none of the affected animations being played. Because of this (and because circular dependencies do not make logical sense anyway), circular dependencies should be avoided, and the dependency flow of animations should only be in one direction

14. Animations ObjectAnimator
takes care of the second part : setting animating values on the object and property
main class in the new animation system
ObjectAnimator.ofFloat(myObject, "alpha", 0f).start();
superclass for classes which provide b
It is possible to set up a AnimatorSet with circular dependencies between its animations. For example, an animation a1 could be set up to start before animation a2, a2 before a3, and a3 before a1. The results of this configuration are undefined, but will typically result in none of the affected animations being played. Because of this (and because circular dependencies do not make logical sense anyway), circular dependencies should be avoided, and the dependency flow of animations should only be in one direction
public void setAlpha(float value); public float getAlpha();

15. Animations View properties
added new properties to the View class in Honeycomb
translationX and translationY
rotation, rotationX, and rotationY
scaleX and scaleY
pivotX and pivotY
x and y
alpha

16. Animations AnimatorSet choreograph multiple animations
ObjectAnimator fadeOut = ObjectAnimator.ofFloat(v1, "alpha", 0f);
    ObjectAnimator mover = ObjectAnimator.ofFloat(v2, "translationX", -500f, 0f);
    ObjectAnimator fadeIn = ObjectAnimator.ofFloat(v2, "alpha", 0f, 1f);
    AnimatorSet animSet = new AnimatorSet().play(mover).with(fadeIn).after(fadeOut);

17. Animations TypeEvaluator
The system knows how to animate float and int values, but otherwise it needs some help knowing how to interpolate between the values you give it
add this interface to the ValueEvaluator
Interface TypeEvaluator {
public abstract T evaluate (float fraction, T startValue, T endValue)
  }