Google GDK: Differences in calling app with voice trigger or menu affecting camera service?

Question

I'm trying to create a Glass GDK app that uses the Camera service to show a preview. Unfortunately, I currently have a bug where a RuntimeException is thrown when trying to open a Camera using Camera.open(). I only encounter this bug when opening the activity through a voice trigger, not by selecting the app from the "launcher" menu.

Is there a difference in how an Activity is launched through this menu versus the voice trigger?

Some of the relevant code is below.

@Override
public void onCreate(Bundle savedInstanceState) {
    mGestureDetector = createGestureDetector(this);
    super.onCreate(savedInstanceState);
    ctx = this;
    act = this;
    setContentView(R.layout.activity_main);
    preview = new Preview(this, (SurfaceView)findViewById(R.id.surfaceView));
    ((FrameLayout) findViewById(R.id.preview)).addView(preview);
    preview.setKeepScreenOn(true);
}

@Override
protected void onResume() {
    super.onResume();
    try {
        if (camera == null) {
        Log.d(TAG, "Opening a camera on resume.");
        camera = Camera.open();
        preview.setCamera(camera);
        camera.startPreview();
        }
    } catch(java.lang.RuntimeException e) {
        Log.e(TAG, e.getMessage());
    }
}

@Override
protected void onPause() {
    if(camera != null) {
        camera.stopPreview();
        preview.setCamera(null);
        Log.d(TAG, "Releasing a camera on pause.");
        camera.release();
        camera = null;
    }
    super.onPause();
}

@Override
protected void onDestroy() {
    if(camera != null) {
        camera.stopPreview();
        preview.setCamera(null);
        Log.d(TAG, "Releasing a camera on destory.");
        camera.release();
        camera = null;
    }
    super.onDestroy();
}

Answer 1

Since it doesn't work when using the voice trigger, it sounds like a possible race condition where the microphone isn't released by the time your activity is displayed on the screen.

Can you try an approach that uses exponential back-off to capture the camera? Basically try to capture the camera and if you get an exception, try again after a short amount of time, increasing the wait time slightly for a fixed number of attempts.

Please also consider filing a bug on the issue tracker, especially if you can reliably find out how much of a delay is needed before the camera/mic can be acquired.