Android 13 Adds Support for Controlling the Brightness of the Flashlight

Mishaal Rahman
|
Try Esper for Free
Learn about Esper mobile device management software for Android and iOS

Mobile LED flashes are practically ubiquitous in Android devices, despite there being no mandate to include them. Still, if an Android device has a rear-facing camera, there’s a very high chance that it’s accompanied by a LED flash module. The LED flash is, of course, used to illuminate subjects while the camera is open, but it’s also able to be used as a general-purpose flashlight by the OS and third-party apps. While Android provides support for toggling the LED flash on or off, it doesn’t provide support for modulating the brightness. That, however, will change in the upcoming Android 13 release.

Among other API additions, Android 13 introduces the getTorchStrengthLevel and turnOnTorchWithStrengthLevel methods to the CameraManager class. The first method returns the brightness level of the LED flash, while the second method sets the brightness level of the LED flash from a minimum of ‘1’ to a maximum determined by the hardware. Previously, apps could only toggle the flashlight on or off using the setTorchMode API, but with these new APIs in Android 13, apps can more granularly control the flashlight brightness.

There is one caveat to this feature, however. Not every device running Android 13 will support controlling the flashlight brightness. Apps can determine if a device supports flashlight brightness control by using CameraCharacteristics.FLASH_INFO_STRENGTH_MAXIMUM_LEVEL. If a value greater than 1 is returned, then that’s the maximum brightness level that the LED flash can be set to. If the value is equal to 1, then the device doesn’t support flashlight brightness control.

The reason support for this feature will be limited is that it will require an update to the camera hardware abstraction layer (HAL). A HAL is the software that defines the interface between the OS and the underlying hardware. In order for the OS to control the LED flash hardware, there needs to be a HAL that defines what commands the OS can issue to control the hardware. On Android, the camera provider HAL allows for direct control of the flash unit of camera devices, a feature that was introduced with version 2.4 of the HAL. The camera provider HAL enumerates and opens individual camera devices, while the camera device HAL is used to operate individual camera devices.

The latest versions of the camera provider and camera device HALs in AOSP — 2.7 and 3.7 respectively — make no mention of flashlight brightness control. However, a brief examination of version 3.8 of the camera device HAL (android.hardware.camera.device@3.8.so), included in the Android 13 Developer Preview for the Pixel 6 Pro, reveals that HAL support for the two new framework APIs has been added. Thus, device makers will likely need to implement version 3.8 of ICameraDevice in order to support Android 13’s new APIs for controlling the brightness of the flashlight.

Flashlight brightness settings
Flashlight brightness settings
Torch-related methods in camera device HAL 3.7 (left) versus 3.8 (right)

Because of the Google Requirements Freeze program, however, it’s possible that many devices upgrading to Android 13 won’t include support for this new feature. This is because, under GRF, Google has frozen its new HAL requirements to ensure that vendor implementations built against version N will be certifiable for up to version N+3. As a result, device makers can upgrade their devices to Android 13 while reusing a vendor implementation designed for an older Android release that doesn’t include the new camera device HAL and its support for LED brightness control. On the other hand, it's likely that even devices with chipsets that aren't part of the GRF program will not support this feature when upgrading to Android 13. As for devices launching with Android 13, it is difficult to say whether those devices will implement ICameraDevice 3.8 or not. This is all dependent on the exact requirements laid out in the vendor software requirements (VSR) for Android 13, which have not been finalized yet. Given the nature of the GRF program, however, it’s likely that only devices whose OEMs upgrade BSPs on their own (like Google with their Pixel devices) and Android 13 launch devices will support this feature.

Still, it is good to see Google add support for user-requested features, especially one that has existed on the other side of the pond for years now.

If you are looking for a tool to manage Android devices, give us at Esper a shout. To get an overview of mobile device management tools, check out our guide: 

Everything You Need to Know about MDM

Featured image source: Shutterstock.com/bluebeyphoto

FAQ

No items found.
No items found.
Learn about Esper mobile device management software for Android and iOS
Mishaal Rahman
Mishaal Rahman

Mishaal Rahman is a Technical Editor at Esper. He has been an Android user for over a decade and has been at the forefront of Android news coverage for half a decade. His in-depth breakdowns of new Android versions have been referenced across the Internet.

Mishaal Rahman

Esper is Modern Device Management

For tablets, smartphones, kiosks, point of sale, IoT, and other business-critical edge devices.
MDM Software

Kiosk mode

Hardened device lockdown for all devices (not just kiosks)

App management

Google Play, Apple App Store, private apps, or a mix of all three

Device groups

Manage devices individually, in user-defined groups, or all at once

Remote tools

Monitor, troubleshoot, and update devices without leaving your desk

Touchless provisioning

Turn it on and walk away — let your devices provision themselves

Reporting and alerts

Custom reports and granular device alerts for managing by exception