Enabling the Camera on AAOS (Pixel Tablet) — It's Disabled by Default

Why This Document Exists

After building and flashing AAOS 14 on a Pixel Tablet, the camera didn’t work. No camera app in the launcher, and sideloading one just throws:

FAILED TO OPEN CAMERA. CAMERA MAY BE IN USE BY ANOTHER APPLICATION? ID:0

The frustrating part: the camera hardware is completely fine. Both sensors are healthy, the HAL is running, and dumpsys sees them. AAOS just ships with the camera switched off at the framework level — a deliberate default for the automotive context.

This document explains how to prove the hardware is fine, the exact root cause (one system property), and two ways to turn the camera back on: baked into the image at build time, or flipped on-device later without rebuilding.

The Symptom

• No camera app in the launcher (AAOS ships none).

• Any sideloaded camera app fails to open the camera: “FAILED TO OPEN CAMERA… ID:0”.

• In logcat, the real errors are:

  E Camera-JNI: android_hardware_Camera_getCameraInfo: Unknown camera ID 0
  W CameraBase: An error occurred while connecting to camera 0: Service not available

To the app, the camera service reports zero cameras and refuses every connection — even though nothing else is using the camera.

The Hardware Is Fine (Prove It First)

Before touching anything, confirm the hardware works. dumpsys runs as shell (user 0) and is not subject to the app-facing block, so it sees the real state:

adb shell dumpsys media.camera | grep -E "Number of camera|Facing|pixelArraySize"

On the Pixel Tablet this shows 2 cameras (front + back), each an 8 MP sensor (3280x2464), with full stream configurations and no errors. The camera processes are alive too:

adb shell ps -A | grep -iE "cameraserver|camera.provider"
# cameraserver
# android.hardware.camera.provider@2.7-service-google

So the block is purely in the software layer sitting in front of the hardware.

The Diagnostic Journey

The chain that led to the root cause, in case you hit a variant of this:

1. Hardware ok — dumpsys media.camera sees 2 cameras, no errors.

2. App sees 0 cameras — the errors come from the legacy Camera (API1) path (CameraBase, Camera-JNI).

3. Not SELinux — getenforce is Enforcing, but there are no avc: denied lines for the app or camera.

4. Allowed user IDs: is empty in dumpsys media.camera — a symptom: the camera service considers no user allowed to open a camera. (On a working device it lists the foreground user, e.g. 10.)

5. The cause: getprop | grep camera reveals the switch:

   [config.disable_cameraservice]: [true]

Flip that to false, restart the framework, and everything falls into place: Allowed user IDs: 10, the app shows up under Active Camera Clients, and a live preview appears.

Root Cause: config.disable_cameraservice

This one system property gates the entire app-facing camera service. It’s set to true in both property files that ship in the image:

/system/build.prop:  config.disable_cameraservice=true
/vendor/build.prop:  config.disable_cameraservice=true

It’s read by the camera framework (framework.jar + services.jar). When true, CameraService reports zero cameras to every app and rejects all connections with “Service not available”. It is a default of the AAOS car product configuration — in a car, the tablet-facing camera is off on purpose.

The hardware, HAL, and cameraserver all keep running regardless; only the app-facing gate is closed. That’s why dumpsys (running as a privileged shell) sees the cameras while apps see nothing.

Fix Option 1: Bake It Into the Image (Build Time)

The clean, permanent fix — survives reflashing because it’s part of the image. Do this in your AOSP tree (for us, on the Hetzner build server under ~/aaos_on_pixel, not on the Mac).

Find where the car product config sets the property:

cd ~/aaos_on_pixel
grep -rn "disable_cameraservice" packages/services/Car device/ build/ vendor/

Then either change that default to false, or — cleaner, because it doesn’t touch upstream files — override it in your own device makefile that’s included last:

# Re-enable the app-facing camera service on this AAOS build
PRODUCT_PRODUCT_PROPERTIES += config.disable_cameraservice=false

Rebuild and reflash:

source build/envsetup.sh
lunch aosp_tangorpro_car-ap1a-userdebug
m
# then flash as in the build guide

Lesson Learned: The property lands in both /system/build.prop and /vendor/build.prop. A PRODUCT_PRODUCT_PROPERTIES override wins over the car-product default, so you don’t have to hunt down and patch the upstream line.

Fix Option 2: Flip It On-Device (Later, No Rebuild)

Already have a flashed tablet and don’t want to rebuild? Change build.prop directly on the device. This needs a userdebug build (adb root) with dm-verity disabled — which is the normal state for these dev images.

Persistent (survives reboot, until the next flash)

# 1. Root + make partitions writable
adb root
adb remount

# 2. Back up first (safety net)
adb shell 'cp -f /system/build.prop /system/build.prop.cambak'
adb shell 'cp -f /vendor/build.prop /vendor/build.prop.cambak'

# 3. Flip the property in both files
adb shell 'sed -i "s/^config.disable_cameraservice=true/config.disable_cameraservice=false/" \
  /system/build.prop /vendor/build.prop'

# 4. Verify (both must read =false, no =true left)
adb shell 'grep -n disable_cameraservice /system/build.prop /vendor/build.prop'

# 5. Reboot
adb reboot

After boot, getprop config.disable_cameraservice reads false on its own and dumpsys media.camera shows Allowed user IDs: <current user>.

Quick & dirty (runtime only, resets on reboot)

If you just want to test it for one session without editing files:

adb root
adb shell setprop config.disable_cameraservice false
adb shell stop && adb shell start   # restart the framework so it re-reads the prop

Revert the persistent change

adb root && adb remount
adb shell 'cp -f /system/build.prop.cambak /system/build.prop'
adb shell 'cp -f /vendor/build.prop.cambak /vendor/build.prop'
adb reboot

Lesson Learned: The on-device fix is lost on the next fastboot flashall, because flashing replaces the read-only partitions. If you reflash often, prefer Option 1 (build time). If you’re on a Google pre-built image (no local AOSP tree), Option 2 is your only path.

You Still Need a Camera App

Enabling the service is only half of it — AAOS ships no camera app. Any Camera2-capable app works; Open Camera (open source, on F-Droid) is a good test:

curl -L -o opencamera.apk https://f-droid.org/repo/net.sourceforge.opencamera_96.apk
adb install -r --user 10 opencamera.apk    # --user = current foreground user
adb shell pm grant --user 10 net.sourceforge.opencamera android.permission.CAMERA
adb shell pm grant --user 10 net.sourceforge.opencamera android.permission.RECORD_AUDIO
adb shell am start --user 10 -n net.sourceforge.opencamera/.MainActivity

Lesson Learned: AAOS is multi-user. The foreground “driver” is user 10, while adb shell runs as user 0. Install and grant permissions with --user 10, or the app won’t appear where you’re looking.

Verifying It Works

Confirm the app is actually holding the camera open:

adb shell dumpsys media.camera | sed -n '/Active Camera Clients/,/Allowed user/p'

You want to see something like:

Active Camera Clients:
[
(Camera ID: 0, ..., Client Package Name: net.sourceforge.opencamera)
]
Allowed user IDs: 10

And grab the live preview as proof:

adb exec-out screencap -p > preview.png

Quick Reference

On-device, persistent (no rebuild)

adb root && adb remount
adb shell 'cp -f /system/build.prop /system/build.prop.cambak'
adb shell 'cp -f /vendor/build.prop /vendor/build.prop.cambak'
adb shell 'sed -i "s/^config.disable_cameraservice=true/config.disable_cameraservice=false/" \
  /system/build.prop /vendor/build.prop'
adb reboot
# then install a camera app (Open Camera) for --user 10

In the build (permanent, survives flash)

PRODUCT_PRODUCT_PROPERTIES += config.disable_cameraservice=false

Reference facts