1. Overview

1.1 ODSL - Definition

ODSL (Open Domain Specific Language) is a customized development framework, provided by FaceSec, to assist customization and tailoring the system to business requirements.

Third-party app developers can embed their processes into existing recognition process flows without needing to modify the source code.

The customized secondary development of existing facial recognition process can be complete as simply as: writing the ODSL configuration -> importing it and then installing the third-party app as specified in the configuration file.

Meanwhile, the third-party app can replace the original standby page, the third-party developers can use the standby page to display customized content by designing interaction and invoking facial recognition.sT

1.2 ODSL Modification of Facial Recognition Process Flow

1.3 ODSL Development Summary

1. Write ODSL configuration file odsl.conf

2. Compile the Android App with ODSL-related changes.

3. Import the ODSL file into the device.

4. Install the application and (if any) configuration page onto the device for debugging.

1.4 Third-party Application ODSL Process Embedding Demonstration

In order to illustrate how ODSL can be used to embed external applications functions into the device’s authentication process, the following example of an airport integrating with an external ticket inspection system will be presented.

The airport’s equipment first reads the information on the ticket and retrieves the corresponding ID information. The ID information is read by FaceSec and is to a third-party service (airport) through ODSL. The third-party system checks if the registered ID information is consistent with the details retrieved from the ticket. If the results match, FaceSec will initiate facial comparison and the comparison result will be sent back to the third-party system. The third-party system receives the comparison result, executes its own additional functions, returns a success or failure state back to FaceSec. The FaceSec terminal will then display the corresponding customized prompt details based on the returned success/fail state.

The process is illustrated as follows:

2. ODSL Configuration File Structure

The ODSL configuration file is composed of multiple Actions group., Each Action structure has four parts: [ACTION_NAME] [ACTION_TYPE] [PARAM_1] [PARAM_2]. Each customized action is taken as an Action, and each Action is composed of action name, action type, and action parameters. The action name, action type, and action parameters are separated by spaces. In the configuration file, each Action occupies one line.

ODSL configuration file format

For more details, refer to 2.1-2.3.

2.1 ACTION_NAME

An Action consists of the following twelve behaviors：

2.2 ACTION_TYPE

Action_type consists of 3 types:

• provider

• activity

• service

1. provider: Indicates that a third-party Content provider will be called to interact with a Third-party applications need to implement the specified query interface, which is defined as follows:

public abstract Cursor query (Uri uri,

String[] projection,

String selection,

String[] selectionArgs,

String sortOrder)

The facial recognition application will call the interface to pass in the selectionArgs parameters, and the third-party application needs to read them and parse the data.

When the third-party application returns the query result, it needs to return the data with the cursor field in JSON format:

xxxxxxxxxx
{“result”: true, “message”: “xxxxxx”}

2. activity: Indicates that a third-party Activity will be called to interact with a third-party application.

To start a third-party activity, use startActivityForResult. The third-party application obtains information through intent extra.

xxxxxxxxxx
String data = intent.getStringExtra(“json”);

Get data from com.beeboxes.odsl.ODSLMatchInfo class in JSON string format.

When terminating an activity, the application should terminate using the setResult method. It must also contain two extra parameters, result and message.

xxxxxxxxxx
1.  Intent intent = new Intent();  
2.  intent.putExtra("result", true);  
3.  intent.putExtra("message", "Check successful");  
4.  setResult(Activity.RESULT_OK, intent);  

3. service: Indicates that a third-party Service will be called to interact with a third-party application

The third-party application service communicates through the Android Messenger (android.os.Messenger) class. The parameter definition of the Message object containing the access record is as follows:

message.what = 200 ​ The string key for retrieving the access record can be obtained in the following way:

xxxxxxxxxx
1.  Bundle bundle = msgfromClient.getData();  
2.  String json = bundle.getString("obj");  

2.3 PARAM_1 PARAM_2

3. ODSL Configuration File Guidelines

3.1 ODSL Data Transfer

ODSL data transmission refers to the information transmitted by ODSL to third party applications and the secondary verification results returned by them back to ODSL.

3.1.1 Data type passed by ODSL to third-party applications

The structure of the data class com.beeboxes.odsl.ODSLMatchInfo passed by ODSL to third-party applications is as follows.

xxxxxxxxxx
1.  public class ODSLMatchInfo {  
2.      ODSLAction action;                      // ODSL Action  
3.      MATCH_RET_TYPE matchRet;                // Identification result  
4.      PassableParcel passable;                // Document details in 1:1 mode，blank in 1:N  
5.      Person person;                          // Blank in 1:1 mode，Personnel details in 1:N mode  
6.      ODSLPersonExtraInfo personExtraInfo;    // Blank in 1:1 mode，Additional personnel details 
7.                                                        // in 1:N mode  
8.      String picPath;                        // Onsite identification snapshot image path  
9.      byte[] lightFeature;                   // Onsite identification image liveness score  
10.    
11.     public enum MATCH_RET_TYPE {       // ODSLMatchInfo matchRet definition，
12.                                            // contains identification results  
13.         SUCCESS,                       // Identification succeeded
14.         CHECK_RULE_FAILED,             // Failed rule check  
15.         MATCH_FAILED,                   // Comparison failed. Typically after liveness 
16.                                           // detection is done and facial scan is saved
17.                                          // Personnel considered not in records if score is lower 
18.                                           // than user-defined threshold
19.         FINGERPRINT_TIMEOUT,          // Fingerprint comparison timeout (8s)
20.         FINGERPRINT_OVERTIMES,        // Fingerprint comparison max. tries (5 failures in a row)
21.          FINGER_1N_SUCCESS,            // Fingerprint 1:N verification success
22.     }  
23. }  

3.1.2 ODSL Function Returns

• When ACTION_TYPE = provider

• Input: com.beeboxes.odsl.ODSLMatchInfo class (direct import) in JSON format.

• Output: Result in JSON format (boolean success_or_fail, String message).

Example: {"result": "true", "message":"Verification successful"}

• When ACTION_TYPE = activity

Input: Intent string extra "json"，com.beeboxes.odsl.ODSLMatchInfo class in JSON format.

Output: Intent boolean Extra "result", returns result.

Intent string extra "message", returns details.

3.2 ODSL Action

The rules for writing different Action behavior configuration files are as follows.

Note: only one ACTION_TYPE can be selected per Action.

3.2.1 card_verify Card detected

The ACTION_TYPE supported by card_verify is <provider/activity>.

• When ACTION_TYPE = provider

Input: com.beeboxes.odsl.ODSLMatchInfo class (direct import) in JSON format.

Output: Result in JSON format (boolean success_or_fail, String message).

Example: {"result": "true", "message":"Check successful"}

• When ACTION_TYPE = activity

Input: Intent String extra "json", JSON object of com.beeboxes.odsl.ODSLMatchInfo class.

Output: Intent boolean Extra "result", result.

Intent String extra "message", response message.

3.2.2 check_after_face_match_11 After successful identification in 1:1 mode

The ACTION_TYPE supported by check_after_face_match_11 is <provider/activity>.

• When ACTION_TYPE = provider

Input: com.beeboxes.odsl.ODSLMatchInfo class in JSON format.

Output: Result in JSON format (boolean success_or_fail, String message).

Example: {"result": "true", "message":"Check successful"}

• When ACTION_TYPE = activity

Input: Intent String extra "json", JSON object of com.beeboxes.odsl.ODSLMatchInfo class.

Output: Intent boolean Extra "result", result.

Intent String extra "message", response message.

3.2.3 check_after_face_match_1n After successful identification in 1:N mode

The ACTION_TYPE supported by check_after_face_match_1n is <provider/activity>.

• When ACTION_TYPE = provider

Input: com.beeboxes.odsl.ODSLMatchInfo class in JSON format.

Output: Result in JSON format (boolean success_or_fail, String message).

Example: {"result": "true", "message":"Check successful"}

• When ACTION_TYPE = activity

Input: Intent String extra "json", JSON object of com.beeboxes.odsl.ODSLMatchInfo class.

Output: Intent boolean Extra "result", result.

Intent String extra "message", response message.

3.2.4 check_after_face_match_mixed After successful identification in hybrid mode

The ACTION_TYPE supported by check_after_face_match_mixed is <provider/activity>.

• When ACTION_TYPE = provider

Input: com.beeboxes.odsl.ODSLMatchInfo class in JSON format.

Output: Result in JSON format (boolean success_or_fail, String message).

Example: {"result": "true", "message":"Check successful"}

• When ACTION_TYPE = activity

Input: Intent String extra "json", JSON object of com.beeboxes.odsl.ODSLMatchInfo class.

Output: Intent boolean Extra "result", result.

Intent String extra "message", response message.

3.2.5 post_match_record Retrieve access record

• ACTION_TYPE of post_match_record supports only .

Input: Uploads should be Bundle class of JSON format.

Output: JSON result obtained can be converted in an identification record of the AccessRecord class.

3.2.6 switch_standby Standby page

• ACTION_TYPE of switch_standby supports only .

Output: Directly returns the activity of the custom standby page.

3.2.7 card_converter Card data conversion

The program converts and outputs hexadecimal strings by default. If other conversions are required, such as decimal string output, card_converter can be used.

• ACTION_TYPE of card_converter supports only .

Input: com.beeboxes.odsl.ODSLCardConverertInfo class in JSON format.

Output: Returns JSON result of (boolean success_or_fail, String converted_no).

3.2.8 check_after_face_match_11_failed After failed identification in 1:1 mode

The ACTION_TYPE supported by check_after_face_match_11_failed is <provider/activity>.

• When ACTION_TYPE = provider

Input: com.beeboxes.odsl.ODSLMatchInfo class in JSON format.

Output: Result in JSON format (boolean success_or_fail, String message).

Example: {"result": "false", "message":"Check failed"}

• When ACTION_TYPE = activity

Input: Intent String extra "json", JSON object of com.beeboxes.odsl.ODSLMatchInfo class.

Output: Intent boolean Extra "result", result.

Intent String extra "message", response message.

3.2.9 check_after_face_match_1n_failed After failed identification in 1:N mode

The ACTION_TYPE supported by check_after_face_match_1n_failed is <provider/activity>.

• When ACTION_TYPE = provider

Input: com.beeboxes.odsl.ODSLMatchInfo class in JSON format.

Output: Result in JSON format (boolean success_or_fail, String message).

Example: {"result": "false", "message":"Check failed"}

• When ACTION_TYPE = activity

Input: Intent String extra "json", JSON object of com.beeboxes.odsl.ODSLMatchInfo class.

Output: Intent boolean Extra "result", result.

Intent String extra "message", response message.

3.2.10 check_after_face_match_mixed_failed After failed identification in hybrid mode.

The ACTION_TYPE supported by check_after_face_match_mixed_failed is <provider/activity>.

• When ACTION_TYPE = provider

Input: com.beeboxes.odsl.ODSLMatchInfo class in JSON format.

Output: Result in JSON format (boolean success_or_fail, String message).

Example: {"result": "false", "message":"Check failed"}

• When ACTION_TYPE = activity

Input: Intent String extra "json", JSON object of com.beeboxes.odsl.ODSLMatchInfo class.

Output: Intent boolean Extra "result", result.

Intent String extra "message", response message.

3.2.11 check_finger_1n_success After successful fingerprint verification in 1:N mode

On successful fingerprint verification in 1:N mode, the ODSL process will be initiated. The user can retrieve the success status by parsing if

ACTION_TYPE == ODSLConfigParser.ACTION_CHECK_FINGER_1N_SUCCESS or MATCH_RET_TYPE == MATCH_RET_TYPE.FINGER_1N_SUCCESS.

• When ACTION_TYPE = provider

Input: com.beeboxes.odsl.ODSLMatchInfo class in JSON format.

Output: Result in JSON format (boolean success_or_fail, String message).

Example: {"result": "false", "message":"Check failed"}

3.2.12 check_before_qrcode_verify Before QR code verification

After a QR code is successfully recognized by the terminal, the device will then compare it with another one issued by the application. Before this comparison, the ODSL process can be initiated to substitute its own comparison process or other customized processing. This can then be used to enable custom applications and functions that rely on QR code recognition.

The ACTION_TYPE supported by check_before_qrcode_verify is <provider/activity>.

• When ACTION_TYPE = provider

Input: com.beeboxes.odsl.ODSLMatchInfo class in JSON format.

Output: Result in JSON format (boolean success_or_fail, String message).

Example: {"result": "false", "message":"Check failed"}

• When ACTION_TYPE = activity

Input: Intent String extra "json", JSON object of com.beeboxes.odsl.ODSLMatchInfo class.

Output: Intent boolean Extra "result", result.

Intent String extra "message", response message.

4. Configuration File Writing and Import Procedures

4.1 Action configuration files examples

Each configuration command in the configuration file is used to specify the package name and class name of the external application to be called after the identification process, or the URL of the provider that jumps to after the card is detected. It also includes configuration parameters such as timeout time, or identification record package name specifications.

E.g.:

xxxxxxxxxx
Configuration format for data return after card identification:

card_verify provider url timeout

Configuration format for data return after 1:1 comparison:

check_after_face_match_11 provider url timeout

Configuration format for access record return:

post_match_record service packagename serviceclassname

Users can refer to the following configuration file content to write their own ODSL configuration file. The configuration file is named odsl.conf, and the content of the configuration file is as follows:

xxxxxxxxxx
card_verify provider content://com.beeboxes.ot.AProvider1000

#card_verify activity com.beeboxes.ot com.beeboxes.ot.AnActivity

#check_after_face_match_11 activity com.beeboxes.ot com.beeboxes.ot.AnActivity

#check_after_face_match_1n activity com.beeboxes.ot com.beeboxes.ot.AnActivity

#check_after_face_match_mixed activity com.beeboxes.ot com.beeboxes.ot.AnActivity

check_after_face_match_11 provider content://com.beeboxes.ot.AProvider 2000

check_after_face_match_1n provider content://com.beeboxes.ot.AProvider 2000

check_after_face_match_mixed provider content://com.beeboxes.ot.AProvider 2000

post_match_record service com.beeboxes.ot com.beeboxes.ot.AService

switch_standby activity com.beeboxes.st com.beeboxes.st.MainActivity

check_after_face_match_11_failed provider [content://com.beeboxes.ot.AProvider](content://com.beeboxes.ot.AProvider/success) 2000

check_after_face_match_1n_failed provider [content://com.beeboxes.ot.AProvider](content://com.beeboxes.ot.AProvider/success) 2000

check_after_face_match_mixed_failed provider [content://com.beeboxes.ot.AProvider](content://com.beeboxes.ot.AProvider/success) 2000

check_finger_1n_success provider [content://com.beeboxes.ot.AProvider](content://com.beeboxes.ot.AProvider/success) 2000

check_before_qrcode_verify provider [content://com.beeboxes.ot.AProvider](content://com.beeboxes.ot.AProvider/success) 2000

4.2 Custom process ODSL configuration file demonstration

Developers can use their own apps to intercept the recognition results generated by FaceSec facial recognition devices and auxiliary processing. The process is illustrated as follows:

Face detected → Start FaceSec recognition process → Verification success/failure→ External app intercepts the recognition result for secondary processing → External app returns the verification success/failure result to FaceSec → FaceSec displays the verification success/failed result.

After a is successful/failed face recognition by FaceSec, the process will be handed over to the external application with their own verification processes. FaceSec will then display the results of this external verification process.

• After the identification process, if the third party provides an interface for further verification, use activity with the action format is as follows: check_after_face_match_xx activity packagename.classname

A configuration file example is as follows:

check_after_face_match_11 activity com.beeboxes.ot com.beeboxes.ot.AnActivity

check_after_face_match_1n activity com.beeboxes.ot com.beeboxes.ot.AnActivity

check_after_face_match_mixed activity com.beeboxes.ot com.beeboxes.ot.AnActivity

• After the identification process, if the third party does not have an interface for further verification, use provider with the action format is as follows:

check_after_face_match_xx provider url timeout

A configuration file example is as follows:

check_after_face_match_11 provider content://com.beeboxes.ot.AProvider 2000

check_after_face_match_1n provider content://com.beeboxes.ot.AProvider 2000

check_after_face_match_mixed provider content://com.beeboxes.ot.AProvider 2000

check_after_face_match_11_failed provider content://com.beeboxes.ot.AProvider 2000

check_after_face_match_1n_failed provider content://com.beeboxes.ot.AProvider 2000

check_after_face_match_mixed_failed provider content://com.beeboxes.ot.AProvider 2000

4.3 Custom prompt message template file modification

4.3.1 Custom prompt file example

Users can modify the custom prompt message template file messageTpl.json, according to the customization requirements. The content of the file is referenced as follows:

xxxxxxxxxx
1.  {  
2.    "templateList": [  
3.      {  
4.        "messageType": "success",  
5.        "ttsText": "Verification successful",  
6.        "title": " Verification successful ",  
7.        "detailText": "Welcome #DB&NAME#",  
8.        "showTime": "1000"  
9.      },  
10.     {  
11.       "messageType": "oneOneSuccess",  
12.       "ttsText": " Verification successful",  
13.       "title": " Verification successful",  
14.       "detailText": Welcome #DB&NAME#",  
15.       "showTime": "1000"  
16.     },  
17.     {  
18.       "messageType": "fail",  
19.       "ttsText": "Verification failed",  
20.       "title": "Verification failed. Please retry.",  
21.       "detailText": "",  
22.       "showTime": "1000"  
23.     },  
24.     {  
25.       "messageType": "oneOneFail",  
26.       "ttsText": "Verification failed",  
27.       "title": "Verification failed. Please retry.",  
28.       "detailText": "",  
29.       "showTime": "1000"  
30.     },  
31.     {  
32.       "messageType": "invalid",  
33.       "ttsText": "",  
34.       "title": " No valid face detected",  
35.       "detailText": "",  
36.       "showTime": "1000"  
37.     },  
38.     {  
39.       "messageType": "blockedPerson",  
40.       "ttsText": "",  
41.       "title": "Access denied",  
42.       "detailText": "",  
43.       "showTime": "1000"  
44.     },  
45.     {  
46.       "messageType": "placeCard",  
47.       "ttsText": " Please put your ID on the reader",  
48.       "title": " Please put your ID on the reader ",  
49.       "detailText": "",  
50.       "showTime": "0"  
51.     },  
52.     {  
53.       "messageType": "faceScreen",  
54.       "ttsText": "",  
55.       "title": "Please face the screen",  
56.       "detailText": "",  
57.       "showTime": "0"  
58.     },  
59.     {  
60.       "messageType": "cardVerity",  
61.       "ttsText": "",  
62.       "title": "Verifying card…",  
63.       "detailText": "",  
64.       "showTime": "0"  
65.     },  
66.     {  
67.       "messageType": "afterFaceMatch11",  
68.       "ttsText": "",  
69.       "title": "T01468",  
70.       "detailText": "",  
71.       "showTime": "0"  
72.     },  
73.     {  
74.       "messageType": "afterFaceMatch1n",  
75.       "ttsText": "",  
76.       "title": " Verifying...",  
77.       "detailText": "",  
78.       "showTime": "0"  
79.     },  
80.     {  
81.       "messageType": "afterFaceMatchMixed",  
82.       "ttsText": "",  
83.       "title": " Verifying…",  
84.       "detailText": "",  
85.       "showTime": "0"  
86.     }, {
87.       "messageType": "afterFinger1n",
88.       "ttsText": "",
89.       "title": " Verifying…",
90.       "detailText": "",
91.       "showTime": "0"
92.     }, {  
93.       "messageType": "cardVerityTimeout",  
94.       "ttsText": "Connection timeout",  
95.       "title": " Connection timeout",  
96.       "detailText": "",  
97.       "showTime": "0"  
98.     },  
99.     {  
100.          "messageType": "duplicateRecognition",  
101.          "ttsText": "",  
102.          "title": "Please wait a moment",  
103.          "detailText": "",  
104.          "showTime": "1000"  
105.        },  
106.        {  
107.          "messageType": "oneNRuleCheckFailed",  
108.          "ttsText": "",  
109.          "title": "Rule permissions check failed",  
110.          "detailText": "",  
111.          "showTime": "1000"  
112.        }  
113.      ]  
114.    }  

4.3.2 Parameter description

1. The messageType represents the message type, which is used to confirm which recognition result the message applies to, such as success and failed states.

2. ttsText represents the text that will be converted from text to speech.

3. title represents the recognition result prompt text to be displayed on the first line.

4. detailText indicates the recognition result prompt text to be displayed on the second line.

5. showTime represents the display duration, in milliseconds.

4.3.3 Custom prompt file string parameters

1. Text wrapped by hexes (#) represent customized text, inclusive of 3 parameters, separated by (&). The combination of the three parameters enables the splicing and display of complex strings from database fields.

Fields that can be spliced between the double # include NAME UUID AGE GENDER PHONE EMAIL ENTRY_DATA ORGANIZATION VARIABLE1~10.

2. The first parameter can be set to two types, namely DB and DEFAULT, which define if the subsequent parameter data should be retrieved from storage or from memory.

Note: Only in 1:N mode, will name, address and other information be obtained from the database DB. In the 1:1 mode, user information is obtained from the presented card. The information that can be extracted depends on how much information is provided by the type of card presented. For example, name, gender, ethnicity, birthday, address, issue date, expiry date and other information can be extracted from ID cards and passports. However, only name can be extracted from IC card, QR code and Wiegand devices.

3. The second parameter is the key value. For example, NAME will return the String in the NAME field retrieved.

4. The third parameter denotes the text display length. If blank, the default is to display the full text. This is primarily used in scenarios where it is unwanted or impractical to display the full length, such as in displaying the full name an individual in a greeting “Welcome, Mr. X” where X is the individual’s last name.

Note: The order of offer must strictly follow the order in the defined template. Otherwise, displayed text will be distorted. In the same way, the number of offers must be strictly consistent with the number of template custom parameters defined, otherwise the displayed text may also be distorted.

4.4 Importing/Deleting configuration files

1. Import or delete the configuration file odsl.conf through the menu Settings -> Advanced → Custom Process. The configuration file will take effect immediately after being imported.

2. Import the edited messageTpl.json custom prompt message configuration file through the menu Settings -> Advanced -> Prompt Message -> Smart Prompt -> Prompt Message

5. ODSL Custom Settings

ODSL provides some in-depth customization setting, which are stored in SettingManager, to enable tailoring to certain specific business scenarios. If an external application needs to access these setting items, a simple interface can be implemented in the application configuration interface, and the set/get and setting of these configurations can be called via SettingsManager.getInstance().set(String key, String value).

In order to complete these setting customizations, it is still necessary to import the odsl.conf file first, as it forms the foundation of all interactions with external services.

5.1 Prompt display duration settings

When ODSL is utilized, after the recognition process performs the assigned checks and returns a failure, it can return a customized failure prompt message, customizable to application requirements. This information is displayed on the facial recognition interface and also has a TTS voice prompt. In some cases, when the process failure prompt message is relatively long, the terminal may start the next recognition process before the end of the TTS playback. The setting items provided here are used to set the display time (in milliseconds) of the prompt information within the different recognition stages.

xxxxxxxxxx
Key:
BBoxUtils.ODSL_MSG_DISPLAY_TIME_CARD_VERITY_FAILED
ODSL card_verify process’s failure prompt message’s display duration 
BBoxUtils.ODSL_MSG_DISPLAY_TIME_AFTER_11_SUCCEEDED
ODSL 1:1 recognition process’s success prompt message’s display duration 
BBoxUtils.ODSL_MSG_DISPLAY_TIME_AFTER_11_FAILED
ODSL 1:1 recognition process’s failure prompt message’s display duration 
BBoxUtils.ODSL_MSG_DISPLAY_TIME_AFTER_1N_SUCCEEDED
ODSL 1:N recognition process’s success prompt message’s display duration 
BBoxUtils.ODSL_MSG_DISPLAY_TIME_AFTER_1N_FAILED 
ODSL 1:N recognition process’s failure prompt message’s display duration 
BBoxUtils.ODSL_MSG_DISPLAY_TIME_AFTER_FINGERPRINT_SUCCEEDED
ODSL fingerprint recognition process’s success prompt message’s display duration 
BBoxUtils.ODSL_MSG_DISPLAY_TIME_AFTER_FINGERPRINT_FAILED
ODSL fingerprint recognition process’s faliure prompt message’s display duration
Value：
Defined in milliseconds. for example. E.g., 2000 is 2s duration. If not set, the default value is 0

5.2 Setting for inclusion of onsite snapshot in access records

The ODSLMatchInfo class is a wrapper class for data interaction between the identification Action (check_after_face_match_11 / check_after_face_match_1n / check_after_face_match_mixed) and external applications. The onsite snapshot image may be required in certain use cases. To accomplish this, the property on the inclusion of the snapshot can be set. If necessary, ODSL will save the snapshot locally and get the absolute path of the picture through ODSLMatchInfo.getPicPath(). Only one copy of the picture will be kept, and the next spot photo will overwrite the last spot photo.

xxxxxxxxxx
Key：

•         BBoxUtils.ODSL_AFTER_MATCH_WITH_PIC

Value：

true: Retain snapshot

•         false: Discard snapshot

5.3 Setting to include feature value in transmitted data

ODSL will get the feature value through ODSLMatchInfo.getLightFeature().

xxxxxxxxxx
Key：

•         BBoxUtils.CORE_FR_MATCH_SAVE_FEATURE

Value：

•          true：ODSLMatchInfo includes feature value

•         false：ODSLMatchInfo does not include feature value

5.4 Enabling and calling external application configuration page

The ODSL customization settings need to be completed by calling the external application’s configuration. Therefore, external applications will need to have created their own Settings Activity, and the Activity of the configuration page must be marked in the Manifest. This will allow the device’s Setting application to detect an external configuration page. The Manifest tag applied on the external configuration page is as follows:

xxxxxxxxxx
    <category android:name="beeboxes.intent.category.SETTING" />

The Setting program will go to PMS (Package Manager Service) to query all activities marked with this category, and then start the entry Activity on the external configuration page.

After installing the external configuration application, it can be started through Settings -> Advanced -> External Application.

6. Appendix

6.1 ODSL Custom Recognition Flow Modification

1. To use the ODSL function, the custom prompt message setting should be changed to "Smart prompt". The setting path is Settings -> Advanced -> Prompt Message -> Smart Prompt.

2. Create and edit the odsl.conf configuration file to specify the external applications that need to be started.

3. Import the edited odsl.conf configuration file from the flash disk via Settings -> Advanced -> Custom Process.

4. Install the officially signed external application Example App to the device (you can install it by adb install). The package name of the external application must match the configuration file. You can refer to the allinone App in the example code. The external application UI configuration page can be activated in Settings -> Advanced -> External Application.

5. Open the facial recognition application and verify the ODSL process.

6.2 ODSL custom prompt configuration

1. Modify the custom prompt message configuration file messageTpl.json.

2. Import the edited messageTpl.json custom prompt message configuration file through Settings -> Advanced -> Prompt Message -> Smart Prompt -> Prompt Message.

6.3 Code samples

1. AnActivity: Sample code when ODSL Action is type activity.

2. AProvider: Sample code when ODSL Action is type provider.

3. AService: Sample code when ODSL Action is type service.

4. ODSLConfigActivity: Sample code for configuring additional settings via ODSL.

5. IcCardProvider: Sample code for IC card data conversion.

6.4 Installing External Apps to Terminal Device

After the external application is completed, it must be signed before it can be installed on the terminal device. You can use adb install to install the signed App. The following describes how to install and debug the officially signed App to the terminal.

1. Enter the settings interface -> Click the "About this machine" option -> Click on the "About this machine" at the top center of the screen three times -> Enter the NetConfig interface.

2. In the NetConfig interface -> Click the "set adb port" and "get local IP" buttons -> The local IP address will be displayed at the bottom of the screen. (Example: 192.168.220.3)

3. Check the "Enable adb debugging" option.

4. Use a PC to connect to the WiFi on the same network segment as the deviice, and execute the following command to install the external app:

>adb connect 192.168.220.3 (terminal IP address)

>adb install -r 3rd_app_signed.apk