This post was originally meant as a placeholder while I was sketching ideas for a longer write-up on Android game development. Rather than leave it empty, I’m turning it into a concise reference for APIs that game programmers tend to touch first when working on Android.

This is not a full game engine tutorial. Think of it as a mental map.

Core building blocks

Activity and Lifecycle APIs

Games on Android live inside an Activity. Understanding lifecycle callbacks (onCreate, onPause, onResume) is critical, especially for handling interruptions like app switching, phone calls, or screen locks.

If your game ignores lifecycle events, it will behave badly on real devices.

SurfaceView and rendering

Most Android games start with SurfaceView or TextureView to get direct access to a drawing surface. These APIs allow you to manage your own render loop without fighting the standard UI thread.

This is usually where developers transition from “Android app” thinking to “game loop” thinking.

Canvas and basic drawing

For 2D games, the Canvas API is often enough:

  • drawing sprites and shapes
  • handling simple animations
  • prototyping mechanics quickly

You don’t need OpenGL on day one.

Input handling

Touch input (onTouchEvent, MotionEvent) is the primary control mechanism on mobile. Games typically bypass standard widgets and work directly with raw input events for responsiveness.

Multi-touch support becomes important sooner than you expect.

Audio APIs

Short sound effects are commonly handled via SoundPool, while longer background tracks use MediaPlayer. Managing audio correctly — especially across lifecycle events — is one of the easiest places to introduce bugs.

Timing and game loops

Android doesn’t provide a “game loop” abstraction. Most games implement their own loop using a dedicated thread, Choreographer, or scheduled updates tied to frame rendering.

Consistency matters more than raw speed.

A note on engines

If you’re using a full game engine (Unity, LibGDX, etc.), many of these APIs are wrapped or abstracted away. Still, understanding what’s underneath helps when debugging performance, lifecycle issues, or platform-specific quirks.

Note: This post was originally a placeholder in 2020 and was updated in 2026 to serve as a concise reference instead of an empty stub.

I prefer publishing small, useful reference posts over leaving unfinished outlines lying around.