Facial Recognition API Migration - Android Dev

## Job Title

Android Java Developer – Facial Recognition API Migration & Liveness Integration

## Project Overview

We have an existing Android application written in Java that currently uses Microsoft Azure Face API for facial-recognition-based attendance and related functions.

We are developing our own self-hosted facial recognition API in Python, using technologies such as InsightFace / ArcFace, ONNX Runtime, FastAPI, and project-specific face repositories.

We need an experienced Android Java developer to review the existing application, understand the current Azure Face API integration, and modify the application so it can work reliably with our new Python facial-recognition API.

The work will be completed in two phases.

## Phase 1 – Replace Azure Face API Integration

The developer will:

* Review the existing Android Java source code.
* Identify all areas where Azure Face API is currently used.
* Understand the current enrollment, recognition, verification, attendance, and image-upload workflow.
* Remove or isolate Azure-specific code.
* Integrate the Android application with our new Python REST API.
* Send captured face images to the new API using secure HTTP POST requests.
* Pass the correct project ID with each recognition or enrollment request.
* Handle multiple independent projects, where each project has its own separate facial dataset.
* Support approximately 500 enrolled faces per project initially.
* Start with at least two separate project datasets.
* Correctly process API responses including:

* matched / not matched
* person or employee ID
* similarity/confidence score
* no face detected
* multiple faces detected
* low-quality image
* invalid project
* API/server errors
* Maintain the existing attendance and business logic unless changes are specifically required.
* Ensure attendance is recorded only after a valid recognition result.
* Handle network failures, API timeouts, retries, and temporary server unavailability gracefully.
* Prevent duplicate attendance submissions caused by repeated scans or retries.
* Keep UI responsiveness good while recognition requests are being processed.
* Ensure API calls do not run on the Android main/UI thread.
* Support concurrent usage from many Android devices.
* Help test the Android application against a target backend capacity of approximately 100 face scans per minute.
* Preserve compatibility with the current application workflow as far as practical.
* Remove Azure Face API credentials and dependencies once the new API is fully validated.

## Expected API Flow

Typical recognition flow:

Camera Capture
→ Android app captures image
→ image is compressed appropriately
→ Android sends HTTP POST request to Python API
→ request includes project ID and image
→ Python API performs face detection and recognition
→ API returns JSON result
→ Android validates response
→ attendance is recorded using the returned person/employee ID

Typical API request may contain:

* project_id
* image
* device ID if required
* timestamp if required
* authentication/API token

Typical response may contain:

```json
{
"success": true,
"matched": true,
"project_id": "1001",
"person_id": "EMP123",
"similarity": 0.89
}
```

The developer must work with the backend developer to agree the final API request and response structures.

## Important Project Architecture

There may be many customer/project datasets.

Each project must remain isolated.

For example:

Project 1001
→ approximately 500 faces
→ separate face repository/index

Project 1002
→ approximately 500 faces
→ separate face repository/index

The Android application must always send the correct project ID so the Python API searches only the appropriate facial dataset.

The Android developer is not responsible for designing the facial recognition AI model itself, but must understand the API sufficiently to integrate it correctly.

## Phase 2 – Liveness / Anti-Spoofing

After the new recognition API is working reliably, we want to introduce facial liveness checking.

The purpose is to reduce the risk of attendance being recorded using:

* printed photographs
* another phone displaying a photograph
* screenshots
* recorded video
* other basic spoofing attempts

The developer will work with us to integrate the chosen liveness solution.

This may involve passive or active liveness.

### Passive Liveness

The system analyses one or more camera frames automatically without asking the user to perform an action.

Examples may include:

* anti-spoofing model analysis
* texture/depth clues
* screen/print attack detection
* motion/frame consistency

### Active Liveness

The app may ask the user to perform an action such as:

* blink
* turn head left/right
* look in a direction
* move closer
* perform another random challenge

The final approach will be decided after technical testing.

## Phase 2 Requirements

The Android developer should:

* Integrate the agreed liveness workflow into the existing camera flow.
* Ensure facial recognition occurs only after liveness passes.
* Prevent replay of previously captured successful liveness requests where practical.
* Support randomised challenges if active liveness is selected.
* Send any required frames/video/images to the Python backend.
* Handle liveness API responses.
* Display clear messages to the user when liveness fails.
* Avoid making the attendance process unnecessarily slow.
* Help test against printed photo and screen-based spoof attempts.
* Work with the Python developer on any required anti-spoofing API endpoints.

Expected final flow:

Camera
→ face detected
→ liveness check
→ liveness passed
→ facial recognition
→ employee identified
→ attendance recorded

If liveness fails:

Camera
→ liveness failed
→ recognition/attendance rejected

## Technical Skills Required

Strong experience with:

* Android development in Java
* Android Studio
* Camera / CameraX / camera integration
* REST APIs
* HTTP POST requests
* Multipart image uploads
* JSON parsing
* Retrofit, OkHttp, Volley, or equivalent networking libraries
* Background threads / asynchronous API calls
* Android permissions
* image capture and image compression
* error handling and retries
* authentication/token handling
* existing codebase review and modification

Useful experience:

* facial recognition applications
* biometric attendance applications
* Azure Face API
* Python/FastAPI integrations
* liveness / anti-spoofing systems
* OpenCV
* InsightFace / ArcFace
* ONNX-based systems

## Important Clarification About Data

Our existing employee/customer/business records are already maintained in our own systems/database.

The main concern here is specifically the facial-recognition workflow.

The Android developer should not redesign our general employee database unless required for integration.

The new Python facial-recognition backend will maintain or access the facial AI data/embeddings associated with each person and project.

## Performance Expectations

Initially:

* approximately 500 enrolled people per project
* at least 2 projects
* approximately 400 facial scans per project per day
* API should be designed to support approximately 100 scans per minute during busy periods
* multiple Android devices may submit scans concurrently

The Android application must therefore handle simultaneous requests cleanly and must not freeze or crash during recognition.

## Security Requirements

The developer should:

* not hard-code sensitive API credentials unnecessarily
* use HTTPS
* securely handle API tokens
* avoid exposing server credentials
* validate server responses
* prevent obvious duplicate/replay attendance submissions where practical
* preserve project separation
* follow reasonable Android application security practices

## Deliverables

Phase 1:

* review of current Android Java code
* identification of Azure-related integration points
* working integration with our Python facial-recognition API
* enrollment integration
* recognition integration
* attendance workflow integration
* correct project ID handling
* error handling
* concurrent/network testing
* removal or disabling of Azure Face API dependency after approval
* documented source code changes
* buildable Android project

Phase 2:

* liveness-check integration
* anti-spoofing workflow
* backend/API coordination
* test cases for photo/screen spoof attempts
* working attendance flow requiring successful liveness
* documented source code changes

## Before Starting

The selected developer should first review the existing application and confirm:

1. Where Azure Face API is currently called.
2. How images are captured and submitted.
3. How enrollment currently works.
4. How recognition currently works.
5. How attendance is recorded after recognition.
6. What Azure-specific IDs or data are currently stored.
7. Which networking library the application currently uses.
8. Whether any Azure SDK libraries are being used directly.
9. What changes will be required to migrate to a generic REST API.
10. Whether the current camera flow can later support liveness checking without major redevelopment.

We prefer a developer who can understand and modify an existing production Android application rather than rebuild the application unnecessarily.