Build an Android flashlight app using the camera torch

Building an Android flashlight app with camera flash support is a focused project with a useful result: one dependable torch control without opening the camera view. The app can work offline, stay lightweight and give users quick access during a power cut, a late walk or a trip through an unfamiliar street.

Australian users provide useful design cues. People commonly call a handheld flashlight a “torch” and a smartphone a “mobile”, so this language makes the interface feel familiar. Households and campers around the Blue Mountains, Kakadu and remote outback highways appreciate quick access during summer storms or power outages. Google Play is the main Android storefront in Australia, where free utility apps are judged quickly by their reliability, download size and battery use.

Plan the torch experience

Start with a simple state model covering the torch being off, on, unavailable or blocked by a permission or camera conflict. The primary screen should contain one large button, clearly labelled “Turn torch on” or “Turn torch off”. This reduces confusion and makes the app easier to operate with one hand, including while wearing gloves.

Decide early whether the torch should remain active when the screen locks. A foreground service with a persistent notification provides the most reliable screen-off behaviour, while a basic in-app version may stop when the process ends. Avoid adding unnecessary timers, accounts or remote configuration until the core on-and-off experience works reliably across real devices.

Set up the Android project

Create a Kotlin Android project with a single activity and a minimum SDK of 23 or later. A single screen with XML layouts is sufficient, although Jetpack Compose works equally well. Use a ViewModel and observable state for the torch status, then let the activity collect that state and update the button. The platform CameraManager API provides everything required, so CameraX and a full camera preview are unnecessary.

A native torch does not need a DigitalOcean Droplet, phpMyAdmin or a remote database. If a larger project includes a web dashboard hosted on a Droplet with phpMyAdmin, keep that server-side work separate from the handset’s camera control. You can compare broader implementation ideas through project templates, but the Android application itself should remain simple and capable of operating without a network connection.

Control the camera torch

Use CameraManager to inspect the available cameras and select the rear-facing camera whose characteristics report an available flash. Store its camera ID in memory, call setTorchMode(cameraId, enabled) when the user changes the state, and release the reference when it is no longer needed. There is no need to request a camera image or display a preview, which keeps power consumption and development complexity low.

The app should also respond when another application opens the camera, because the operating system may disable the torch. Register a torch availability callback on the main thread and update the interface when availability changes. Apply short haptic feedback after a successful command, but do not rely on vibration as the only confirmation. The visible button and accessibility announcement should always reflect the actual state.

Handle permissions and hardware differences

Declare the CAMERA permission in the manifest and request it at runtime when the user attempts to switch on the torch. Also declare the camera flash as an optional hardware feature with android.hardware.camera.flash set to false. This lets the app install on tablets or phones without a flash while still showing a clear “Torch unavailable” message.

Physical-device testing is essential because emulators often cannot reproduce real torch behaviour. Check recent Samsung, Google Pixel, Motorola and lower-cost Android models, along with devices popular through Australian mobile retailers. Test denied permissions, incoming calls, camera launches, rotation, low battery and rapid repeated taps. Each error path should leave the button disabled rather than leaving the interface claiming that the torch is on when it is not.

Design practical features for Australian users

A polished torch should be visually obvious and accessible. Use a high-contrast theme, a large touch target, scalable text and a TalkBack description that communicates the next action. Respect the device’s locale and Australian English spelling, while avoiding slang that could make a safety-related control less clear.

The following release recommendations cover the features that matter most for Australian Android users:

Call the feature a “torch” and label the main button with its next action.
Keep the core function offline, with no account, advertising SDK or mandatory data collection.
Provide clear states for unavailable hardware, denied permission and camera conflicts.
Support large text, high contrast and accessible touch targets without clipped labels.
Test on Samsung, Pixel, Motorola and budget Android hardware sourced through Australian retailers.
Use a foreground service only when reliable screen-off operation is required, and show an ongoing notification.

The app can also use a restrained red or amber theme, but colour should never be the only way to communicate status. If analytics are added later, explain what is collected and assess obligations under the Australian Privacy Principles instead of assuming a generic consent banner is sufficient.

Test and release the app safely

Run unit tests for the state transitions and instrumented tests for permission and hardware behaviour, then complete a manual checklist on several physical devices. Release candidates should be distributed through Google Play’s internal testing track before reaching the Australian public store. The listing should state that the camera permission is used for torch control, while a privacy notice confirms that the app does not upload images or location data.

Android release builds normally use R8 for shrinking and obfuscation. A practical ProGuard configuration guide explains how to preserve required classes and verify the resulting APK. Obfuscation is not a substitute for secure storage or secret management, so never hard-code API keys in the project. Test the signed release build on a clean phone to confirm that permissions, callbacks and foreground-service behaviour still work after shrinking.

Create the project today, install the prototype on your own Android phone and publish a free Google Play release that Australians can trust from the first tap.