Android Notes

Windowmanager:

The Android WindowManager is a system service, which is responsible for managing the z-ordered list of windows, which windows are visible, and how they are laid out on screen.
Among other things, it automatically performs window transitions and animations when opening or closing an app or rotating the screen.

Every activity has a Window that is used to display its content on the screen. When you call setContentView on an activity, it attaches that view to the activity's default window. The default window fills the screen, so that your activity's window hides any other activities -- the WindowManager will display whichever window is on top. So normally you don't need to worry about windows - you just create an activity and Android will do the rest for you.

you need to interact with the WindowManager if you want to do something unusual like create floating windows that don't fill the screen.
https://www.youtube.com/watch?v=kjGPE_XLmwg

Activity Lifecycle:

onCreate()

This is the first callback and called when the activity is first created.

onStart()

This callback is called when the activity becomes visible to the user.

onResume()

This is called when the user starts interacting with the application.

onPause()

The paused activity does not receive user input and cannot execute any code and called when the current activity is being paused and the previous activity is being resumed.

onStop()

This callback is called when the activity is no longer visible.

onDestroy()

This callback is called before the activity is destroyed by the system.

onRestart()

This callback is called when the activity restarts after stopping it.

An activity class loads all the UI component using the XML file available in res/layout folder of the project.Following statement loads UI components from res/layout/activity_main.xml file:

setContentView(R.layout.activity_main);

ActivityManager:

This class gives information about, and interacts with, activities, services, and the containing process.

A number of the methods in this class are for debugging or informational purposes and they should not be used to affect any runtime behavior of your app. These methods are called out as such in the method level documentation.

Most application developers should not have the need to use this class, most of whose methods are for specialized use cases.

Binder:
Most apps and core system services depend on Binder
Most app component life-cycle call-backs (e.g. onResume(), onDestory(), etc.) are invoked by ActivityManagerService via binder Turn off binder, and the entire system grinds to a halt (no display, no audio, no input, no sensors, …)

Binder driver is exposed via /dev/binder and offers a relatively simple API based on open, release, poll, mmap, flush, and ioctl operations.

Canvas

Canvas is the Android class which application developers would use to draw widgets, pictures etc. In Android versions Froyo and Gingerbread Canvas would do the drawing using Skia.  Android Honeycomb and onward, HWUI was added as an alternate GPU-accelerated option. Android Ice Cream Sandwich (ICS) and onward, HWUI is the default.

Skia

Skia is a 2D drawing API which is used by applications and works completely in software.  For performance reasons Skia is slowly being replaced by HWUI.

HWUI

The HWUI library enables UI components to be accelerated using the GPU. HWUI was introduced in Honeycomb to make the user interface fast, responsive and smooth.  Since tablets had very high resolutions, using Skia for effects like animation would have been too CPU intensive and slow. HWUI requires an OpenGL ES 2.0 compliant GPU which cannot be emulated by software on Android.

Applications written in canvas can use SKIA or HWUI.

Surface

A Surface in Android corresponds to an off screen buffer into which an application renders the contents. An application might be a game which uses OpenGL to draw 3D objects directly into a surface or a normal application which uses Skia to draw widgets, text, etc. It could even use HWUI library to enable a GPU accelerated user interface. From Android ICS, surfaces are implemented with a SurfaceTexture backend which means instead of a buffer, a texture is used.

SurfaceFlinger

SurfaceFlinger is the compositor that manages multiple surfaces from various apps. For example, there could be many running applications with independent Surfaces that are being rendered. SurfaceFlinger determines what will be shown on the screen and does overlays as needed.

SurfaceFlinger uses only the functions in the OpenGL ES 1.1 standard.  If SurfaceFlinger used functions in OpenGL ES 2.0, it would require GPU hardware and drivers to be working – which would complicate bring-up on new devices and the Android emulator.

HW Composer

HW Composer is a Hardware Abstraction Layer (HAL) introduced in Honeycomb that is used by SurfaceFlinger to efficiently perform composition using hardware resources like a 3D GPU or a 2D graphics engine.

CopyBit

CopyBit was a hardware abstraction layer (HAL) which allowed the use of special hardware that can speed up some graphics operations like blitting etc. It was used to accelerate software rendering on systems without 3D GPUs. CopyBit support was removed in ICS, since GPUs became mandatory for supporting the newer user interface.

Libagl/PixelFlinger

libagl is the library which implements the OpenGL ES 1.0 & 1.1 API in software. It uses PixelFlinger to implement the OpenGL calls. To speed up the rendering using PixelFlinger, a just in time compiler (JIT) was introduced called CodeFlinger. CodeFlinger generates direct machine code which drastically speeds up many types of pixel operations.