This guide provides a comprehensive list of configurable properties for the Android Registration Client. Please note that this list is not exhaustive but serves as a helpful checklist for reviewing commonly configured properties.
It is important to acknowledge that all properties listed in this guide are automatically synchronized with the Android Registration Client. These properties are sourced from the registration-default.properties
file.
application-default.properties
registration-default.properties
Timeouts in milliseconds set during any http calls to SBI.
Quality score threshold based on modality, Possible values 1 to 100
Retry attemps, Possible values 1 to 10
Quality score threshold based on modality for operator authentication, Possible values 1 to 100`
Jobs like RID sync, packet upload, status sync is carried out in batches, number of registration records to be executed in a batch on every trigger.
Default CRON expression for scheduling the Jobs.
mosip.registration.sync_jobs_restart_freq=0 0 */11 ? * *
Enables / disables reviewer authentication on any biometric exception during registration
mosip.registration.reviewer_authentication_configuration=Y
If enabled, cross-checks of residents biometrics with locally stored operator biometric templates.
mosip.registration.mds.deduplication.enable.flag=N
Minimum disk space required to create a packet - in MB
mosip.registration.disk_space_size=5
Maximum no. of days for approved packet pending to be synced to server beyond which Registration Client is frozen for registration
mosip.registration.last_export_registration_config_time=100
No. of days beyond audit creation date to delete audits
mosip.registration.audit_log_deletion_configured_days=10
Maximum duration to which registration is permitted without sync of master data
mosip.registration.sync_transaction_no_of_days_limit=5
Allowed number of invalid login attempts
mosip.registration.invalid_login_count=50
Configuration used to check if any sync job is missed/ failed beyond expected days, this configuration is checked everytime operator clicks on any registration process. We follow below convention to create this config key.
mosip.registration.job api name as in sync_job_def table.frequency=value in days
Date format to be displayed on acknowledgement slip, default value - dd/MM/yyyy hh:mm a
mosip.registration.application_date_format
Date format to be displayed on Registration Client dashboard, default format - dd MMM hh:mm a
mosip.registration.dashboard_date_format
Due to the absence of UI specifications in the 1.1.5.x versions, the android regclient addresses backward compatibility by migrating the schema of these versions to the LTS UI Spec structure.
In order to facilitate this migration, certain configurations and templates have been incorporated to ensure compatibility with the 1.1.5.x server. The list of these configurations is provided below.
mosip.registration.consent-screen-template-name=reg-consent-screen-content-template
Consent screen is not a part of 1.1.5.x schema structure. So, we are completely fetching this consent screen content from master.template
table, and the templateTypeCode
for the consent screen content is mentioned in the above configuration.
mosip.registration.individual-biometrics-id=individualBiometrics
The id of individual biometrics should be mentioned in the above property according to the configured 1.1.5.x schema.
mosip.registration.introducer-biometrics-id=guardianBiometrics
The id of guardian/ introducer biometrics should be mentioned in the above property according to the configured 1.1.5.x schema.
mosip.registration.infant-agegroup-name=INFANT
The age-group name for infants (aged below 5 years) which is configured in the configured server should be mentioned in the above property.
mosip.registration.agegroup-config={"INFANT":{"bioAttributes":["face"],"isGuardianAuthRequired":true},"ADULT":{"bioAttributes":["leftEye","rightEye","rightIndex","rightLittle","rightRing","rightMiddle","leftIndex","leftLittle","leftRing","leftMiddle","leftThumb","rightThumb","face"],"isGuardianAuthRequired":false},"SENIOR_CITIZEN":{"bioAttributes":["leftEye","rightEye","rightIndex","rightLittle","rightRing","rightMiddle","leftIndex","leftLittle","leftRing","leftMiddle","leftThumb","rightThumb","face"],"isGuardianAuthRequired":false}}
The above property indicates list of age-groups, required bio-attributes, and a flag which indicates guardian authentication is required or not. This property should be changed according to the server configuration and requirements.
mosip.registration.allowed-bioattributes=leftEye,rightEye,rightIndex,rightLittle,rightRing,rightMiddle,leftIndex,leftLittle,leftRing,leftMiddle,leftThumb,rightThumb,face
The above property defines the list of bio-attributes that are allowed for scanning during registration. If there are any changes in the server, it should be changed accordingly.
mosip.registration.default-app-type-code=000
The above property defines the default applicantTypeCode. In LTS, we have applicanttype.mvel script to fetch the documents according to the age, gender and some other attributes. Based on the applicant details, the script returns an applicantTypeCode which can be any value from “000” to “014”, and respective documents will be fetched from master.applicant_valid_document table
. Since we do not have this script defined in 1.1.5.x to handle this, we have added a default applicantTypeCode
.
Ensure that the preview and acknowledge templates are present in the template table
of mosip_master
database with the following type code:
reg-android-preview-template-part
reg-ack-template-part
The Android Registration Client is a tablet application that serves as a portable version of the existing desktop Registration Client. It has been developed to support accessibility on all Android devices. The existance of Android Registration Client came about in order to meet the mobility requirements of countries adopting MOSIP.
The primary objective of the tablet version is to facilitate the registration process for residents, specifically those who are unable to physically visit registration centres and also serve remote locations where setting up Registration centres is not feasible. To address this challenge, the Android Registration Client was created, enabling Operators/ Supervisors to easily reach the remote areas and maximise resident registrations across the country.
To have a quick glance at the features, refer the video below!
The first developer release of Android Registration Client offers the following key features:
Operator/ Supervisor Login (offline and online): Operators can securely log in using their credentials, whether in offline or online mode, to carry out various registration transactions. To enable offline login, the Operator must have previously logged in and synchronized their data over a network.
Multi-language support: The Android Registration Client supports multiple languages for content display and data entry.
Display Language: Display Language refers to the language used for rendering UI elements such as labels and headings. With the Android Registration Client, Operators have the option to choose their preferred language for UI display. This language selection can be made on the login screen. Currently, the supported display languages include Arabic, French, English.
New languages can be added by following the below steps:
i. Additional languages can be configured by adding localisation files in lib/l10n
folder present in the root project directory("android_registration_client").
ii. The languages that are rendered on the UI will be based on the country configuration (after master data sync). The default display language is English. The other languages will be available in the UI after master data sync.
To know more, refer Flutter doc-Internationalizing Flutter apps.
Data Entry Language: The Data Entry Language refers to the specific language utilized by the Operator while gathering data, which is then stored on the server in that selected language. During the registration process, the Operator can choose the language preference for the data collected, allowing applicants to provide information in their desired language. This language selection option becomes available upon initiating a new registration. The responsibility for managing the data entry language lies within the UI Spec, and any modifications or changes can be made through that specification.
Auto-Sync/ manual sync: On launching the Android Registration Client and logging in for the first time, the system automatically syncs the following data:
Configuration sync: Sync of properties which drives in deciding the ARC UI functionality. For example: Invalid login attempts, idle timeout, thresholds, etc.
Masterdata sync: As a part of this sync, supporting information like Dynamic fields data, templates, locations, screen authorization, blocklisted words, etc. are pulled in.
UserDetails sync: userID, along with their status is synced. Only the user details belonging to machine mapped center will be synced.
Certificate sync: Certificates used to validate the server signatures, device CA certificates, public key (specific to a center and machine, also called as policy key) used to encrypt the registration packet will be synced.
New Registrations : Operators have the ability to register a resident using the New Registration
feature. The registration process can be customized through the UI specification. The required data for registering an applicant are as follows:
Consent: Prior to the registration process, applicants must provide consent to the terms and conditions presented on the consent screen. This explicitly asks the applicant to grant permission for storing and using their Personally Identifiable Information (PII).
Demographic Details: Once the consent is obtained, the Operator will enter the demographic data of the applicant in the language preferred by the applicant. This includes details such as their name, gender, date of birth, and residential address.
Documents Upload: Following the completion of the demographic details, the Operator can select the document type, input the reference, and upload the supporting documents provided by the applicant. Supporting documents may include Proof of Address, Proof of Identity, and Proof of Birth, based on the country-specific requirements.
Biometrics: After the documents have been uploaded, the Operator will proceed to capture the applicant's biometrics. The biometrics captured are as follows:
The acquisition of biometric data is regulated by the country. The country has control over the capture of each type of biometric (fingerprint, iris, or face) through the global configuration. When the Operator selects the Capture button, the biometric SBI application is accessed to capture the biometrics. Once the biometrics are obtained, the data and control are returned to the Android Registration Client. To obtain the resident's biometrics, the quality of the captured image must exceed the threshold specified by the country. The biometrics can be captured set number of times if necessary to meet the quality threshold. In situations where none of the captured images meet the threshold, the image with the highest quality score will be saved.
If the resident has a biometric exception (such as a missing finger/eye or very poor finger/iris quality), the Operator can designate that particular biometric as an exception. However, the Operator must still capture the resident's exception photo.
Preview section: The Operator has the ability to review the data entered by the applicant, including demographic information, uploaded documents, and captured biometrics. This preview allows the Operator to ensure the accuracy of the entered data. If any mistakes are found, the Operator can easily go back to the corresponding section and make the necessary corrections. If the data is correct, the Operator can proceed to the next step, which is to authenticate themselves.
Operator authentication: Once both the Operator and applicant have confirmed that the data is accurately filled, the Operator is required to authenticate themselves using their credentials. After a successful authentication, the data packets are created and only then the sync and upload operations can be performed.
Packet sync: After the applicant's registration form has been completed and the Operator has authenticated themselves, a packet sync must be performed. This can be done either manually or as a background job(auto sync and uplaod of packets). Packet sync ensures that the packet is prepared for uploading and the status of the uploaded packet is synchronized with the server.
Packet Upload: Once the packet sync is successfully completed, the system will proceed to upload the packet to the server when an internet connection is available. If there is no network access, the system will attempt to upload the packet as soon as connectivity is established.
Acknowledgment section: Following the completion of the new registration process, an acknowledgment receipt is generated. This receipt includes the AID(Application ID), captured demographic data in the selected language, a photograph of the resident, and a ranking of each finger from 1 to 10, with 1 representing the finger with the best quality. The receipt is designed to be easily printed.
To read through the comprehensive list of configurable properties for the Android Registration Client, refer Android Registration Client Configuration Guide.
For more details on UI specifications for the Android Registration Client, refer here.
The Android Registration Client is compatible with the following MOSIP platform versions:
1.1.5.x
LTS 1.2.0 and above
The documentation here will guide you through the pre-requisites and the other necessary details required for Android Registration Client developer setup.
The android-registration-client repository contains the Android Registration Client software for MOSIP. The feature-flutter branch focuses on integrating Flutter into the client.
To set up the Android Registration Client with Flutter and Android Studio, follow the steps below:
Flutter SDK (3.10.4): Install Flutter by following the official Flutter installation guide.
Android Studio (or Any IDE of your choice): Download and install Android Studio from the official Android Studio website.
The develop
branch of android-reg-client is currently being actively developed. If you wish to access this branch, you can clone the repository by executing the following command in your terminal. Alternatively, you can download one of the releases available in the repository's release section.
Active Branches:
release-0.9.x(developer release branch)
develop(active development branch)
To begin, launch Android Studio.
Next, select Open an existing Android Studio project and navigate to the cloned repository.
Open the android-registration-client
directory as a project in Android Studio.
In order to integrate Flutter with Android Studio, install the Flutter plugin by accessing File > Settings > Plugins
and searching for Flutter. Proceed to click on Install to install the plugin.
To ensure proper functionality, configure the Flutter SDK path by navigating to File > Settings > Languages & Frameworks > Flutter
and specifying the Flutter SDK path as the location where you have installed Flutter.
Finally, save the changes by clicking on the "Apply" button.
Customising the Registration Client
Styling of the application can be configured by modifying these files lib/utils/app_style.dart, lib/utils/app_config.dart
Application language bundles can be added to this path lib/l10n
.
Label and application logo can be changed here android/app/src/main/AndroidManifest.xml
The pigeon.sh
file consists of the necessary commands for downloading dependencies and generating Flutter - Android native communication code. Please execute the pigeon.sh
file or execute the commands within the file separately.
Ensure you have connected an Android device or initiated an Android emulator.
Open the terminal within Android Studio or use an external terminal.
Navigate to the android-registration-client
directory.
Run the following command in order to build and execute the application:
Excecute the commands below to debug and release the APK
The Mock MDS tool can be utilized to simulate the functionalities of biometric devices. The Mock MDS application is compliant with CTK standards and can serve as a substitute for Android SBI modules during testing and validation.
Install the Mock MDS application.
Access the Settings menu.
Under Device Configuration, choose Registration from the dropdown menu.
In P12 Configuration:
Enter the necessary credentials for the Device Key and upload the Device P12 file.
Enter the required credentials for the FTM Key and upload the FTM P12 file.
Complete all fields in MOSIP IDA Configuration.
In Modality Configuration, specify the quality score for Face, Finger, and Iris scans(these values can also be adjusted during testing).
Click on the Save button.
Go back to the Home Page and select LOAD AND VALIDATE CERTIFICATES
.
A toast message will be displayed indicating the success of the validation process.
Note: To view the released version of the Mock SBI APK, click here.
To download the Mock SBI APK, click on camera-mds.zip
.
If you would like to contribute to the Android Registration Client, please follow the guidelines outlined here.
The Android Registration Client is licensed under the MIT License.
If you encounter any issues or have any questions, please open an issue on the GitHub repository.
GitHub- mosip/android-registration-client: Reference Android Registration Client Software - WIP
This user guide is designed to provide assistance to Operators and Supervisors in successfully installing, running, and registering applicants to obtain their Unique Identification Numbers (UIN) on tablet devices.
Reliable and consistent Internet connectivity.
Tablets running Android version 10 to 13.
Tablets with a minimum of 4 GB RAM.
The tablets need to be capable of capturing fingerprints, iris, and face (photo) biometrics. Additionally, they should also have the ability to scan documents. However, if the tablets do not support these capabilities, MOCK SBI can be used as an alternative.
Download and install the APK on Android tablet.
Once ARC is installed, long press on the logo to copy the machine details.
Go to Resources/Machine
and click on Create machine
Add a new machine and enter the machine details:
Add the specs as Mobile
Map it to a Zone and Center
Add the Machine spec ID as Mobile
Enter Device name
Enter Public Key
Enter Sign Public Key
Create the role Default
in KeyCloak with all the other roles.
Create the Operator’s user account in KeyCloak and set the password and assign the role as Default
, REGISTRATION_OFFICER
, Registration Operator
, REGISTRATION_SUPERVISOR
Login into Admin Portal to perform the following and add the user:
After login into Admin Portal, go to User Zone Mapping
and add the zone for the user and activate the zone.
Go to User Center Mapping
and add the center for the user and activate it.
Note: The user should be assigned to the same Zone and Center as the device.
The user should relaunch the ARC and log in using their valid credentials. Additionally, the operator has the option to select their preferred display language.
Upon successful login, the user will be directed to the Home page, which includes the following options:
New Registration
Operations Tasks (Future scope)
Dashboard (Future scope)
Settings (Future scope)
To begin the Registration process, the Operator is required to follow the steps outlined below.
Click on New Registration card.
Select the language to be used for data entry, which will be used to collect the resident's information. There will be a default language for data entry.
Choose the language in which the notification will be sent to the resident. Click Submit to proceed.
The operator will be redirected to the Consent page, where the resident must agree to the terms and conditions
in order to proceed.
After accepting consent, the Operator will need to fill out the demographic data of the resident, including their name, age, date of birth, and address. Once all mandatory fields are completed, the Continue button will be enabled.
Upon clicking the Continue button, the Operator will be navigated to the Document upload
page where they will need to:
Select the type of document (e.g. proof of identity, proof of address) from the drop-down menu.
Enter the Reference Number of the document.
Upload the document by clicking on the Scan button to open the camera. The Operator can take a picture of the document and then choose from the following actions:
Cancel: Clicking on the "Cross" icon will remove the captured image and return the Operator to the previous screen.
Crop: The Operator can drag from the four corners of the captured image to crop it as needed.
Save: Clicking on the "Save" button will save the captured image and return the Operator to the previous Document Upload page.
Retake: Clicking on the "Retake" button will remove the captured image, reopen the camera, and allow the Operator to take a new photo.
After ensuring all required information has been accurately entered in the Document Upload
screen, the Operator can proceed by clicking on the Continue button to access the Biometric Capture
page. Here, the Operator can capture the biometric data of the Resident, including a face photo, fingerprint, and iris scan.
Face photo capture process
For capturing the face photo, the Operator should click on the Scan button to activate the camera and take a picture.
The image quality will be displayed on the screen and must meet a certain threshold to be considered acceptable.
The Operator has three attempts to capture the biometric image.
It is important to note that no exceptions can be made for the face photo biometric capture process.
Biometric Data capture process:
In order to capture biometric data, the Operator should click on the Scan button.
This will allow the Operator to capture the biometric information.
Once the data is captured, the image quality will be displayed on the screen and must meet the acceptable threshold limit.
Note: Three attempts are provided to capture the biometric data.
Fingerprint Capture Process:
In the event that a thumb is missing or experiencing difficulties that prevent its fingerprint from being captured, the Operator is authorized to indicate an exception. To mark an exception, the operator must select the affected thumb and specify the type of exception as either Temporary or Permanent. Additionally, the operator may include any relevant additional comments.
Iris Scanning Process:
To initiate the Iris scan, the Operator is required to click on the Scan button.
This action will allow the Operator to capture the Iris image.
Once the Iris has been successfully captured, the quality of the image will be displayed on the screen.
It is essential for the quality score to meet the established threshold limit.
The Operator has three opportunities to capture the biometric data.
If one or both of the Irises are not detected or encounter issues that prevent successful capture, the Operator has the option to mark an exception. To do so, the Operator must identify the specific Iris that is problematic and indicate the type of exception- either Temporary or Permanent. Additionally, the Operator may provide any relevant comments.
After all the biometric data has been properly captured or any exceptions have been noted, the Continue button will be activated. The Operator can then proceed by clicking on the Continue button, which will redirect them to the Preview page. The Preview page will display the following information:
Application ID
Timestamp of Registration
Demographic data collected
Documents submitted
Biometric data recorded
From the Preview page, the Operator has the ability to navigate back to previous screens in order to make any necessary adjustments to the entered or captured data. Once the Operator has verified the accuracy of the entered data, they can proceed by clicking on the Continue button, which will direct them to the Operator Authentication
page.
On the Operator Authentication
page, operators are required to input their credentials (username and password) that were used during the login process.
Upon successful verification of the credentials, the packet will be uploaded to the server and the operator will be redirected to the Acknowledgment
screen. This screen includes the following information:
Application ID
Timestamp of Registration
Demographic data captured
Documents uploaded
Biometric data captured
Print option
QR code for the Application ID
Option to initiate a new registration process.
On the acknowledgement page, the operator will have two options available:
Print- The operator can click on this option to obtain a physical copy of the acknowledgement.
New Registration- The operator can initiate another registration by clicking on this option.
In summary, the aforementioned steps can be followed by the user (Operator/ Supervisor) to register an individual by capturing demographic data, documents, and biometric data in order to generate their UIN.
On the , using admin credentials, login and perform the following to add the device:
Upon receipt of the acknowledgement, the packet is uploaded to the . Once the packet has been successfully processed, a unique identification number (UIN) is generated.