FaceMovementChallenge not recognized, still requires FaceMovementAndLightChallenge.

[sothon19931]

Hi team 👋

I’m trying to use the new FaceMovementChallenge in Amplify UI Android on latest version (release v1.6.0).

Here’s my code:

1. On challengeOptions use "faceMovement = LivenessChallenge.FaceMovement(camera = Camera.Front)", I found still display flashing lights.

   What it should be :

• "FaceMovementChallenge" (does not require color reflection) → works with both front and back cameras.
• "FaceMovementAndLightChallenge" → works only with the front camera, because it requires colors to reflect off the user’s face. **only one option can be selected

MaterialTheme(colorScheme = LivenessColorScheme.default()) {
    FaceLivenessDetector(
        sessionId = sessionId,
        region = "ap-northeast-1",
        credentialsProvider,
        disableStartView = false,
        challengeOptions = ChallengeOptions(
            // faceMovementAndLight = LivenessChallenge.FaceMovementAndLight
               faceMovement = LivenessChallenge.FaceMovement(camera = Camera.Front)
        ),
        onComplete = {
            viewModel.fetchSessionResult(sessionId)
            onChallengeComplete()
        },
        onError = {
            if (it is FaceLivenessDetectionException.UserCancelledException) {
                onBack()
            } else {
                viewModel.reportErrorResult(it)
                onChallengeComplete()
            }
        }
    )
}

2. From 1), since using FaceMovementChallenge still shows the flashing lights, I tried removing FaceMovementAndLightChallenge("2.0.0") and using only FaceMovementChallenge("1.0.0"), but then I get this error:

PredictionsException{message=An error occurred during the face liveness flow.,
cause=ValidationException(message=Missing challenge versions or no supported challenge version found.)}

val faceLivenessSessionInformation = FaceLivenessSessionInformation(
    videoWidth = TARGET_WIDTH.toFloat(),
    videoHeight = TARGET_HEIGHT.toFloat(),
    challengeVersions = listOf(
        // Challenge.FaceMovementAndLightChallenge("2.0.0"), // removed
        Challenge.FaceMovementChallenge("1.0.0")
    ),
    region = region,
    preCheckViewEnabled = !disableStartView,
    attemptCount = attemptCounter.getCount()
)

What I’ve observed

• If I include FaceMovementAndLightChallenge("2.0.0") or use only FaceMovementAndLightChallenge, it works fine — and correctly still triggers the flashing lights challenge.
• If I try FaceMovementChallenge("1.0.0") by itself, the session fails with the ValidationException above.

My questions are:

1. Why does this error occur when I only provide FaceMovementChallenge without FaceMovementAndLightChallenge?
2. Did I configure something wrong, or is this the reason why "FaceMovementChallenge" still shows the flashing lights?

[ekjotmultani]

Hi @sothon19931, thank you for raising this issue, we will check why this error occurs given the challenge versions with this flow and get back to you

[tylerjroach]

@sothon19931 The challenge type is not set from the client library. The challenge comes from your session generation logic. challengeOptions is an options class to set the configuration values for both of the challenge types. You need to work with your backend session generation logic to set the challenge type for the specific sessionId.

[sothon19931]

@tylerjroach Thank you for the clarification. I updated the backend session generation logic to include the ChallengeType in the CreateFaceLivenessSession request, and it worked as expected. The client library now correctly receives the challenge type through the sessionId 🎉.

From my testing:

FaceMovementChallenge → confidence score around 86–90%

FaceMovementAndLightChallenge → confidence score around 99%

Is this difference in confidence scores expected behavior between the two challenge types, or are there any recommended configurations to improve the confidence score for FaceMovementChallenge?

[sothon19931]

@tylerjroach Thank you for the clarification. I updated the backend session generation logic to include the ChallengeType in the CreateFaceLivenessSession request, and it worked as expected. The client library now correctly receives the challenge type through the sessionId 🎉.

From my testing:

FaceMovementChallenge → confidence score around 86–90%

FaceMovementAndLightChallenge → confidence score around 99%

Is this difference in confidence scores expected behavior between the two challenge types, or are there any recommended configurations to improve the confidence score for FaceMovementChallenge?

Update: After running multiple tests, I also observed that FaceMovementChallenge confidence scores can reach 99% as well. However, FaceMovementAndLightChallenge appears to provide consistently higher accuracy, with confidence scores staying at 99% under the same environmental conditions.

Thanks again @tylerjroach for the support

[tylerjroach]

https://docs.aws.amazon.com/rekognition/latest/dg/face-liveness.html

When using FaceMovementAndLightChallenge the user’s face moves into the oval displayed on their device, the Amplify SDK displays a sequence of colored lights on the screen. It then securely streams the selfie video to the cloud APIs. Alternatively, when using FaceMovementChallenge, the user’s face moves into the oval displayed on their device, but there are no sequence of colored lights. While 'FaceMovementAndLightChallenge' remains the best setting to maximize accuracy, 'FaceMovementChallenge' allows customers to prioritize faster speed of liveness checks over accuracy. When selecting between these settings, customers should consider their use case requirements including expected attack types, desired false accept and false reject rates, and additional checks such as geolocation (e.g. based on IP), One Time Pass codes (OTPs), etc. Customers should make this decision after testing Liveness performance with various confidence score thresholds on their specific content.

For questions about scores, you would need to reach out to the Rekognition team. The FaceMovementAndLightChallenge is best method for accuracy, as the No Light option removes one of the accuracy checks. I would not assume you are doing anything wrong here, you just may need to evaluate confidence scores for no-light scenarios vs light scenarios when determining your thresholds.