Revision Log

Device Software Version Updates/Compatibility Notes

Version 2.6 of this document is released together with device software version 2.6.0.13. This also marks the initial release.

1. Overview

FaceSec Facial Recognition Terminals development platforms are Android-based, and with provided SDKs, third-party developers can easil develop new functionality for these devices. The development platform provides support for a number of features, including facial recognition process flows, personnel management, rule management, identification record management, setting management, etc.

The image below represents the device’s system architecture, on which subsequent platform systems are designed.

Fig 1.1 FaceSec Facial Recognition Terminals Development Platform System Architecture

2. SDK Integration Guide

2.1 Development Environment & Compilation Overview

Development environment and compilation: Use Android Studio (version 3.0 or above recommended). For project compilation: JDK7 or above, Android SDK 24 or above are required.

2.2 SDK File Import Overview

1. Before using the SDK, it is necessary to add the SDK and the dependent libraries to the corresponding directories in the development application. Using the following sample code as an illustration, these library files should be imported with the corresponding directories.

2. Before deploying the SDK, the following libraries should be added to the the application’s dependencies:

3. the following SDK example, the following classes are usable in third-party development:

3. Personnel Management & Rule Management API Overview

These endpoints facilitate CRUD operations on personnel, performing operations on personnel through ID/UUID; Retrieving rules, updating personnel rules; CRUD operation on recognition parameters, etc.

Personnel Management API Table

3.1 Common Personnel Management API

The main entities covered under personnel management include:

• Ordinary personnel

• Authorized personnel

• Administrators

The following introduces the relevant APIs for the various personnel types.

3.1.1 Common Personnel Management API

All interfaces of this module exist as static methods, which can be called directly using the class name. The calling method is: AppPersonManager.xxx (xxx is the specific interface).

The following is a description of the Adding Personnel interface. For the use of other methods, please refer to Adding Personnel and sample code.

Add Personnel

Sample code:

​x
1.  private void addPerson() {  
2.      AppPersonInfo person = new AppPersonInfo();  
3.      person.setUuid(mEtUuid.getText().toString());  
4.      person.setName(mEtName.getText().toString());  
5.      person.setIdCardNumber(mEtId.getText().toString());  
6.      person.setIcNumber(mEtIc.getText().toString());  
7.      person.setPersonType(0);    //Required. 0 Regular, 1 Guest
8.      AppPersonRule rule = (AppPersonRule) mSpRule.getSelectedItem();  
9.      person.setRuleId(rule.getRuleId());  
10.     int ret = AppPersonManager.addPerson(this, person, mRawImage);  
11.     if (ret == AppPersonManager.SUCCESS) {  
12.         Toast.makeText(this, "Add successed", Toast.LENGTH_LONG).show();  
13.     } else {  
14.         Toast.makeText(this, "Add failed", Toast.LENGTH_LONG).show();  
15.     }  
16. }  

Update Personnel

Retrieve Personnel with feature

Retrieve Personnel without feature

Delete Personnel

Delete All Personnel

Personnel Search Result

Retrieve Personnel List

Extract Facial Features from Image

3.1.2 Authorized Personnel Management API

The authorization personnel management API is similar to the common personnel management interfaces. Refer to the common personnel management API.

The authorized personnel management interface is used during 1:1 comparison. After the comparison is successful, the ID number will need to be rechecked if it has been registered in the device comparison scenario.

Add Authorized Personnel

Update Authorized Personnel

Retrieve Authorized Personnel

Delete Authorizations

Delete All Authorized Personnel

Search Authorized Personnel via ID no.

3.1.3 Administrator Management API

When using the administrator management API, the PersonManager object needs to be instantiated first before methods can be called.

The instantiation is as follows:

The initialization of the PersonManager instance object requires the getFaceManager method of FaceRecognizerManager.PERSON_SERVICE as the parameter of FaceRecognizerManager.

The instantiation sample code is as follows, for specific use, please refer to the ExampleApplication class in the sample code:

xxxxxxxxxx
 mFaceRecognizerManager = FaceRecognizerManager.getInstance(**this**, mServiceConnectionListener,**null**); 

The following is a description of the Adding Administrator interface. For the use of other methods, please refer to Adding Administrator and sample code.

Add Administrator

The sample code is as follows, mPersonService being an instance of PersonManager:

xxxxxxxxxx
1. mAdmin = **new** Administrator(); 
2. mAdmin.setUuid(UUIDGenerator.getUUID()); 
3. mAdmin.setLightFeature(mLightFeature); 
4. mAdmin.setName(mEtName.getText().toString()); 
5. mAdmin.setVerifyType(0); 
6. String encrypt = MD5Utils.encrypt(mEtPassword.getText().toString()); 
7. mAdmin.setPassword(encrypt); 
8. Boolean isSuccess =mPersonService.addAdministrator(mAdmin); 

Delete Administrator

Edit Administrator

Retrieve Administrator

Retrieve All Administrators

Get Administrator Count

Delete All Administrators

3.2 Personnel Rule Management API

All interfaces of this module exist as static methods, which can be called directly by the class name. The calling method is: AppPersonRuleManager.xxx (xxx is the specific interface).

Personnel Rule Management API Overview

The following only gives sample codes for the interface of creating personnel rules. For the use of other interfaces, please refer to Creating Personnel Rules interface and sample code.

Retrieve all Personnel Rules

Retrieve Personnel Rules Matching Search Criteria

Check if Personnel Rule Exists

Update Personnel Rule

Create Personnel Rule Time Period

Create Personnel Rule

Sample code:

xxxxxxxxxx
1. **private** **void** addRule() { 
2. Set<Integer> weekDays = **new** ArraySet<>(); 
3. weekDays.add(1); 
4. weekDays.add(2); 
5. weekDays.add(3); 
6. Range<Range.Time> timeRange = **new** Range<Range.Time>(); 
7. Range.Time start = timeRange.**new** Time(); 
8. start.setHour(0); 
9. start.setMinute(0); 
10. start.setSecond(0); 
11. Range.Time end = timeRange.**new** Time(); 
12. end.setHour(23); 
13. end.setMinute(59); 
14. end.setSecond(59); 
15. timeRange.setStart(start); 
16. timeRange.setEnd(end); 
17. TimeRule timeRule = AppPersonRuleManager.buildTimeRule("TestRuleTitle", TimeRule.Type.CYCLE, **null**, TimeRule.DayType.CUSTOM, weekDays, timeRange, Action.ALLOW); 
18. List<TimeRule> timeRuleList = **new** ArrayList<>(); 
19. timeRuleList.add(timeRule); 
20. List< Rule.AccessType > typeList = **new** ArrayList<>(); 
21. typeList.add(Rule.AccessType.FACE); 
22. AppPersonRuleManager.addRule(**this**, "RuleName", "RuleNameDescription", "prompt", typeList, timeRuleList, **true**); 
23. } 

Create or Edit Personnel Rule

3.3 Recognition Parameters API

All interfaces of this module exist as static methods, which can be called directly using the class name. The calling method is: AppGroupManager.xxx (xxx is the specific interface).

Recognition Parameters API Overview

Add Recognition Parameter Library via Name

Delete Recognition Parameter Library via Name

Retrieve Recognition Parameter Library ID by Name

Check if Recognition Parameter Library Exists by ID

Check if Recognition Parameter Library Exists by Name

Get Recognition Parameter Library Count

3.4 Fingerprint Interface API

SDK version 2.6 supports 1:N fingerprints comparison. Currently, fingerprint information for a maximum of 5000 people can be stored, with a maximum of 2 fingerprints per person.

When calling the fingerprint interface, users should also call the personnel management interface. When adding personnel, the fingerprint adding interface should be called at the same time. When deleting personnel information, the fingerprint delete interface should be called at the same time to ensure the synchronization of personnel and fingerprint information.

The newly-added SDK fingerprint-related interfaces are encapsulated in com.beeboxes.device.DeviceManager. Users can obtain DeviceManager instances through DeviceManager.getInstance(), and then call the fingerprint-related interfaces.

Fingerprint Interface API Overview

Add Fingerprint

Update Fingerprint

Delete Fingerprint

Delete All Fingerprints

Retrieve Fingerprint

Get Fingerprint Count

Register Data Listener

Unregister Data Listener

Add fingerprint sample code: Users can use the data monitoring interface to enter fingerprints information and synchronize it with the fingerprint add/update interface, to implement a full fingerprint registration function.

xxxxxxxxxx
1.  IDataAvailableListener mListener = new IDataAvailableListener() {
2.  
3.      @Override
4.      public void onDataAvailable(Device.Input input, Object o) {
5.          if (input == Device.Input.FINGERPRINT) {
6.              FingerPrint fp = (FingerPrint) o;
7.              byte[] fingerFeature = fp.getFeatures();
8.              Finger finger = new Finger(uuid, fingerFeature, null, null, null, null);
9.              DeviceManager.getInstance().addFinger(finger);
10.         }
11.     }
12. }

3.5 Error Code Definitions

3.5.1 Add Personnel Error Response Details

xxxxxxxxxx
1.  public static final int SUCCESS = 0x1;                 // Success 
2.  public static final int UUID_NULL_ERROR = 0x2;         // Personnel ID is blank  
3.  public static final int UUID_REPEAT =  0x4;            // Non-unique personnel ID  
4.  public static final int UUID_UNDEFINE =  0x8;          // Personnel ID not found  
5.  public static final int UUID_FORMAT_ERROR = 0x10;      // Invalid personnel ID format 
6.  public static final int NAME_NUll_ERROR = 0x20;        // Name is blank  
7.  public static final int NAME_FORMAT_ERROR = 0x40;      // Invalid name format  
8.  public static final int SERVICE_INSERT_ERROR = 0x80;   // Service error  
9.  public static final int FEATURE_ERROR = 0x100;         //Personnel feature retrieval failed  
10. public static final int PARAM_ERROR = 0x200;           // Parameter error  
11. public static final int IC_FORMAT_ERROR =  0x400;      // Invalid IC card format  
12. public static final int WG_FORMAT_ERROR =  0x800;      // Invalid Wiegand format  
13. public static final int GROUP_ID_INEXISTENT = 0x1000;  // Recognition parameter library not found
14. public static final int EXTERN_FORMAT_ERROR = 0x2000;  //Personnel details extension format error  
15. public static final int FR_SERVICE_DISCONNECTED = 0x4000;  // FR SERVICE disconnected  
16. public static final int PERSON_OVER_RANGE_ERROR = 0x8000;  //Exceeded personnel storage capacity  
17. public static final int SEX_FORMAT_ERROR = 0x10000;     // Invalid personnel gender format  
18. public static final int IDCARD_FORMAT_ERROR = 0x20000;   // ID card format error  
19. public static final int RULE_ID_ERROR = 0x40000;        // Personnel Rule ID not found 
20. public static final int UNKNOW = 0x80000;  

3.5.2 Add Recognition Parameter Library Error Response Details

xxxxxxxxxx
1.  public static final int SUCCESS = 0x1;              // Success  
2.  public static final int FAILED = 0x2;               // Failed   
3.  public static final int GROUP_FORMAT_ERROR = 0x4;   // Recognition parameter library format error  
4.  public static final int GROUP_OUT_OF_RANGE = 0x8;   // Recognition parameter library capacity exceeded  
5.  public static final int GROUP_EXISTS = 0x10;        // Recognition parameter library already exists 
6.  public static final int PARAM_ERROR = 0x20;         // Parameter error

4．Settings Management API

Settings management is about providing unified configuration information reading and configuration for the entire platform. Supports the import and export of setting management files in single-host mode, and the platform to send down and upload configuration information.

Settings Management API is pictured below:

Figure 3.1 Settings Management API

Settings Management API Overview

The operations for attribute configuration is as follows.

4.1 Set Attribute

4.2 Get Attribute

4.3 Remove Attribute

4.4 Register Callback Endpoint

5. Access Record API

The access records fields are as below:

xxxxxxxxxx
1.  CREATE TABLE IF NOT EXISTS record  
2.  (  
3.      Id INTEGER PRIMARY KEY AUTOINCREMENT,  
4.      recorduploadflag INTEGER,  
5.      obj TEXT  
6.  );  

Among them, Id is a self-incrementing database field, which can be sorted to get the latest identification record, recorduploadflag is the cloud service mode upload flag bit, the obj field is the JSON data that stores the identification record, and the corresponding entity class is located in the opnext-domain of FaceSec AccessRecord class in the package. You can use fastJson or Gson parsing methods to obtain identification record information. The recorded information includes information such as the person's name, gender, and comparison photos.

An interface is provided for the querying and deletion of FaceSec’s access records through ContentProvider.

The authority and Uri required for obtaining are defined as follows:

xxxxxxxxxx
1.  public static final String AUTHORITY = "com.beeboxes.face.record.provider";   
2.  public static final Uri RECORD_CONTENT_URI = Uri.parse("content://" + AUTHORITY + "/record");  

5.1 Retrieve All Access Records

6. Interface Class API

6.1 Serial Port API Interface

The third-party developers can use the serial ports to connect their own peripherals, and call the serial API interface to implement the serial port applications.

6.1.1 Serial Port Development Checklist

Android devices will need to import the SDK package (com.beeboxes.sdk.jar) to the compileonlylibs directory.

The serial port class is initialized as follows:

xxxxxxxxxx
1.  BBoxSerial serial = (BBoxSerial);
2.  DeviceManager.getInstance().getOutputDevice(Device.Output.SERIAL); 
3.  BBoxSerial.SerialPort sp = serial.createSerialPort(path, 115200);

6.1.2 Serial Port API List

The serial port interface is as follows:

xxxxxxxxxx
1.  void open() throws IOException;  
2.  int read (byte[] buffer, int length) throws IOException;  
3.  int write (byte[] buffer, int length) throws IOException;  
4.  void close() throws IOException;  

6.2 Serial Port API Secondary Wrapper Interface

The third-party developers can transmit user data to PC via serial API, such as Access Record, Log, etc. In order to make development on Android and PC compatible, the Demo of PC is applied the same API design as that on Android.

6.2.1 Serial Port Development Checklist

Write permissions to external media storage are required:

xxxxxxxxxx
android.permission.WRITE_EXTERNAL_STORAGE 

6.2.2 Serial Port API Interface

Serial Port

xxxxxxxxxx
1.  public interface ITansport {  
2.  void open() throws IOException;  
3.  int read(byte[] var1, int var2) throws IOException;  
4.  int write(byte[] var1, int var2) throws IOException;  
5.  void close() throws IOException;  
6.  }  

System Log

xxxxxxxxxx
1.  public interface ILog {  
2.  void log(String var1);  
3.  ｝  

Enable system logging

xxxxxxxxxx
1.  SerialManager.installLogger(mLoger);  
2.  SerialManager.setDebugable(true);  

Two data transmission interfaces are provided

Synchronous transmission：

xxxxxxxxxx
mSerialManager.send(byte[] buffer, int offset, int len);  

Asynchronous transmission：

xxxxxxxxxx
mSerialManager.sendAsync(**byte**[] buffer, **int** offset, **int** len, IDataTransCallback callback); 

File transfer interface

xxxxxxxxxx
mSerialManager.sendFile(String path, IFileTransCallback callback); 

Note: This interface only provides asynchronous transmission interface

Register data listener

xxxxxxxxxx
mSerialManager.registerDataListener(IDataListener listener);

Register file receiver listener

xxxxxxxxxx
mSerialManager.registerFileReceiveListener(IFileReceiveListener listener); 

6.2.3 Instructions for using serial port API on Android

Create serial port class

xxxxxxxxxx
1.  BBoxSerial  = (BBoxSerial)   
2.  DeviceManager.getInstance().getOutputDevice(Device.Output.SERIAL)；  
3.  mSerialManager = new SerialManager(serial.createSerialPort(path, baud));    

Register data listener. When a client sends data, it will call back to the user through this interface

xxxxxxxxxx
SerialManager.registerDataListener(mDataListener); 

Register file receiver listener. When a file is received，the user will be notified of its progress and completion through this interface

xxxxxxxxxx
mSerialManager.registerFileReceiveListener(mFileReceiveListener); 

Enable transfer mode. This command must be executed before a data transfer can be executed

xxxxxxxxxx
mSerialManager.startTransfer(); 

Stop transfer, when the port is no longer in use

xxxxxxxxxx
mSerialManager.stopTransfer(); 

6.2.4 Instructions for using serial port API on PC

Import the serial SDK library SerialTransport.jar on the PC to the libs directory

xxxxxxxxxx
1.  import com.beeboxes.device.serial.transport.ITansport;  
2.  import com.beeboxes.device.serial.transport.SerialManager;  

Create a serial port management class: SerialManager is used to manage the serial port

xxxxxxxxxx
1.  SerialPort serial = new SerialPort(path, baud);   
2.  mSerialManager = new SerialManager(serial);  

Register data listener. When a client sends data, it will call back to the user through this interface

xxxxxxxxxx
1.  mSerialManager.registerDataListener(mDataListener);   

Register file receiver listener. When a file is received，the user will be notified of its progress and completion through this interface

xxxxxxxxxx
mSerialManager.registerFileReceiveListener(mFileReceiveListener); 

Enable transfer mode. This command must be executed before a data transfer can be executed

xxxxxxxxxx
mSerialManager.startTransfer();

Stop transfer, when the port is no longer in use

xxxxxxxxxx
mSerialManager.stopTransfer();  

7. Device Management API Overview

7.1 Door Control API

7.1.1 Dry Contact Door Control API

Control a door through dry contact by setting the DoorCmdInfo class and setting the door parameter DoorCmd.

xxxxxxxxxx
1.  public class DoorCmdInfo {
2.      private DoorCmd mCmd = INVALID;
3.  
4.      public enum DoorCmd {
5.          INVALID,
6.          OPEN,
7.          CLOSE,
8.          ALWAYS_OPEN,
9.      }
10. 
11.     public int setCmd(DoorCmd cmd) {
12.         mCmd = cmd;
13.         return 0;
14.     }
15. }

Interface call sample:

xxxxxxxxxx
1. DoorCmdInfo doorCmdInfo = **new** DoorCmdInfo(); 
2. doorCmdInfo.setCmd(DoorCmdInfo.DoorCmd.OPEN); 
3. mDeviceManager.sendCmd(doorCmdInfo.getDeviceType(), doorCmdInfo); 

Description：setCmd can also call the door unlock command DoorCmdInfo.DoorCmd.ALWAYS_OPEN。

7.1.2 Wiegand Door Control API

There are a number of Wiegand protocols, which need to be updated for deployment. Set the parameters of the corresponding protocol, corresponding to the WgConfig class. For specific parameters, please refer to the following class description.

xxxxxxxxxx
1.  public class WgConfig implements Parcelable {
2.      private Type mType = Type.WG_none;
3.  
4.      private int mAllBits;
5.      private int mDataBits;
6.      private boolean bCheck = false;
7.      private int mOCheckBits;
8.      private int mECheckBits;
9.      private int mPulseWidth;
10.     private int mPulseInterval;
11. 
12.     public static enum Type {
13.         WG_none,
14.         WG_26,
15.         WG_34,
16.         WG_36,
17.         WG_64,
18.         WG_Custom,
19.         WG_Max
20.     }
21. }

The Type value is the different protocol types of Wiegand. For different type values, you need to set the corresponding mAllBits, mDataBits and other parameters.

Interface call example:

xxxxxxxxxx
1.  DeviceManager outDevManager = DeviceManager.getInstance();   
2.  Wiegand wiegand = (Wiegand) outDevManager.getOutputDevice(Device.Output.WIEGAND);  
3.  wiegand.sendCardId(WgConfig.Type.WG_26, wgNumber);  

Parameters: Wiegand wgNumber, user data, defined by the user.

Description：Wiegand parameter configuration can be set through the system configuration menu.

7.2 Wiegand Parameters Description

Only access control devices have Wiegand related configuration, and the Wiegand parameter configuration can be opened in the menu Basic -> Advanced -> Access Control Signal. Wiegand parameters can be configured with general Wiegand types, or custom types, defining pulse interval width, total number of bits, number of data bits, and parity.

Interface call example:

xxxxxxxxxx
DeviceManager outDevManager = DeviceManager.getInstance();  

Wiegand wiegand= (Wiegand) outDevManager.getOutputDevice(Device.Output. WIEGAND); 

Wiegand.setConfig(WgConfig wgConfig)

Parameter: wgConfig, the parameter definition of Wiegand output, see the table below.

7.3 RS485 Port API

RS485 serial port API is an ordinary serial port that is automatically converted by hardware, and the software interfaces are consistent, so software development can use [6.1 Serial API Basic Interface].

7.4 Fill Light API

7.4.1 Visible Light Lamp API

Visible light has three colors: red, green, and white. Among them, only white can be adjusted for brightness, red and green are not adjustable and can only be turned on and off.

Interface call example:

xxxxxxxxxx
DeviceManager outDevManager = DeviceManager.getInstance();  

SupplementLight light = (SupplementLight) outDevManager.getOutputDevice(Device.Output.SUPPLEMENT_LIGHT); 

light.setBrightness(brightness); 

Parameters: brightness, the brightness value is defined by the user, the range is 0-255.

7.4.2 Infrared Lamp API

Infrared lamp. Brightness is adjustable.

Interface call example:

xxxxxxxxxx
DeviceManager outDevManager = DeviceManager.getInstance();  

SupplementLight light = (SupplementLight) outDevManager.getOutputDevice(Device.Output.SUPPLEMENT_LIGHT); 

light.setNirLight(brightness); 

Parameters: brightness - the brightness value is defined by the user, the range is 0-255.

7.5 Card Reader API

Calling the card reading interface. IDCARD provided as an example:

xxxxxxxxxx
DeviceManager mDeviceManager = DeviceManager.getInstance();   
mDeviceManager.registerDataAvailableListener(Device.Input.IDCARD, this);
public void onDataAvailable(final Device.Input type, final Object device) {
        if（type ==  IDCARD） {
            final BBoxIDCard idcard = (BBoxIDCard) device;
        }
}

Parameter: The IDCARD class data returned by the device can be converted into the BBoxIDCard class to obtain various information of the ID card. The class information is shown in the table below.

Description: The card reader module mainly uses the registered listener, and the App only needs to process the required data in the callback. This scheme is common to other Input and Output devices.

The following are some class descriptions of card readers.

7.6 Fingerprint Reader API Development

An example of calling the interface of the fingerprint module. The DeviceManager instance must be retrieved first, and then call the relevant interface:

xxxxxxxxxx
DeviceManager mDeviceManager = DeviceManager.getInstance();   
mDeviceManager.registerDataAvailableListener(Device.Input.FINGERPRINT, this);
public void onDataAvailable(final Device.Input type, final Object device) {
      if（type ==  FINGERPRINT） {
         final FingerPrint fp = (FingerPrint) device;
         byte[] features = fp.getFeatures(); //Retrieve fingerprint feature
         Photo photo = fp.getPhoto(); //Retrieve fingerprint image
        }
}

Parameters: The fingerprint FingerPrint data returned by the device can be converted to the FingerPrint class to obtain the characteristic value data of the fingerprint. The class is shown in the table below.

Description: The fingerprint module is mainly called through the register listener; the App only needs to process the required fingerprint data in the callback.

7.6.1 Fingerprint 1:1 Comparison API

1: 1 fingerprint comparison is generally used for the one-to-one comparison of ID cards. It needs to be used in conjunction with 3.5 IDCard. When ID card information is read and the ID card information contains fingerprint information, the Fingerprint comparison interface can be called.

Interface call example:

xxxxxxxxxx
DeviceManager mDeviceManager = DeviceManager.getInstance();   
mDeviceManager.registerDataAvailableListener(Device.Input.IDCARD, this);
public void onDataAvailable(final Device.Input type, final Object device) {
      if（type ==  IDCARD） {
           final BBoxIDCard idcard = (BBoxIDCard) device;
           byte[] fp = idcard.getFP(); //Fingerprint data retrieved from the card
           if (fp != null) {
                 MatchResult result = mDeviceManager. matchFingerPrint(); //1:1 fingerprint comparison
             }
         }
}

Parameter: MatchResult is the result of fingerprint comparison, detailed information is shown in the table below.

7.6.2 Fingerprint 1:N Comparison API

1:N fingerprint comparison is generally used for most comparison scenarios. The fingerprint data of N needs to be stored in advance, then a fingerprint is read and compared against it. Because the fingerprint information is embedded in the personnel information, refer to section 3.4 "Fingerprint Interface API" for the specific fingerprint-related addition, deletion, and modification API can.

Interface call example:

xxxxxxxxxx
String uidName = "zhangsan"; //UID represents a personnel’s details
byte[] finger0 = new byte[512];
byte[] finger1 = new byte[512];
byte[] finger2 = new byte[512];
byte[] finger3 = new byte[512];
byte[] finger4 = new byte[512];
// The above 5 fingerXs should be filled with the characteristic value of the actual fingerprint.
    
Finger finger = new Finger(uidName, finger0, finger1, finger2, finger3, finger4);
addFinger(finger); //Add fingerprint data
updateFinger(finger); //Or update an existing fingerprint object
    
DeviceManager mDeviceManager = DeviceManager.getInstance();   
mDeviceManager.registerDataAvailableListener(Device.Input.FINGERPRINT, this);
public void onDataAvailable(final Device.Input type, final Object device) {
       if（type ==  FINGERPRINT） {
             final FingerPrint fp = (FingerPrint) device;
             byte[] features = fp.getFeatures(); // Get the current fingerprint feature value
             MatchResult result = mDeviceManager. matchFingerPrintsN(features); //1:N Fingerprint comparison
         }
}

Parameter: MatchResult is the result of fingerprint comparison, see the class description for details.

7.7 Proximity sensor p-sensor API

Proximity sensor p-sensor interface call example：

xxxxxxxxxx
   DeviceManager mDeviceManager = DeviceManager.getInstance();   
   Proximity mProximity = mDeviceManager.getOutputDevice(Device.Output.PROXIMITY);
   mProximity.registerDistanceListener(mIDistanceListener);
   mIDistanceListener = new IDistanceListener() {
    @Override
    public void onDistance(int distance) {
    }
};

Parameters: distance returned by the current measured distance, in millimeters. The normal test range is 0-800mm, and the error range is plus/minus 5mm, limited to indoor environments.

Description: The short-range P-Sensor module mainly uses the register listener method, and the App only needs to process the required data in the callback.

8. Facial Recognition Process Trigger Interface Description

Supported face recognition triggers

• ID/Card trigger (only in 1:1 comparison mode)

• Automated trigger (On face detection)

• External trigger. Can be done with manual triggers through the device or the PC

External trigger steps:

• Set CORE_FR_MATCH_API_CALLED attribute to true

• Then start the face method of MainActivity through Intent.

Interface call example:

xxxxxxxxxx
1.  SettingsManager.getInstance().set(BBoxUtils.CORE_FR_MATCH_API_CALLED, "true");  
2.  ComponentName componentName = new ComponentName("com.opnext.face", "com.opnext.face.MainActivity");  
3.  Intent intent = new Intent();  
4.  intent.setComponent(componentName);  
5.  startActivity(intent);  

9. Glossary

• FaceSec’s Facial Recognition Terminal Platform: device software platform with open development support, and support for customizable business processes support through ODSL. The terminal itself supports functions such as the management of personnel, the setting of general and identification parameters, and the storage and upload of identification records.

• FaceSec Facial Recognition Cloud Management Platform: referred to as cloud management platform; a back-end management system that coordinates and manages cloud service mode devices. The platform supports unified management and operation of batch terminals, the management of personnel and organizations and related access permissions, the management of platform account permissions, and the management of platform applications.

• Single-host mode: One of the two operating modes of the device. It does not synchronize with the cloud platform and connects to the internet independently. In this mode, the terminal can add and manage personnel and access permissions locally, and stores access records locally.

• Cloud service mode: One of the two operating modes of the device, used in conjunction with the platform. In this mode, both the platform and the device manage the device's facial recognition related parameter settings, and access records will be automatically uploaded to the cloud platform.

• Terminal operating mode: The operating modes of the devices are divided into single-host mode and cloud service mode. The difference between the two is that the cloud service model is used with the cloud management platform, while the single-host model indicates the device functions independently. In cloud service mode, the cloud management platform can issue commands to the device.

• Personnel rules: access rules for personnel, which describe when and via which verification methods personnel can use with the device, or when the personnel are not allowed to attempt to access through the device.

• Device rules: the device’s access rules, describing the time periods during which the terminal will allow personnel to attempt access. Device rules are a combination of device time attributes and device group parameters. Priority is higher than personnel rules. Will take the intersection of the result of personnel rules when judging access rights.

• 1:N mode: refers to the current single snapshot (1) and the personnel library (N individuals) are compared N times in sequence. Derives the score of N and take the highest score as the best choice. If the highest score exceeds the set threshold, the comparison passes and the two images are considered as having the same subject. Otherwise, the comparison fails and the two are considered distinct.

• 1:1 mode: refers to a comparison between a single snapshot (1) and a specified photo (1). Dervies a score, which if it exceeds the set threshold, the comparison is determined to be successful, and the two are considered to contain the same subject. Otherwise, the judgment fails and the two are considered distinct. There are two ways to obtain designated photos: 1. Swipe an ID card and read the photos stored in the ID card. 2. Swipe IC card or enter through Wiegand and search for the corresponding personnel's photo in the database by card number.

• Hybrid mode: Support 1:N mode at the same time on the basis of supporting 1:1 mode.

• Access records: personnel access records, the records generated by personnel after verification on the terminal, including captured photos, passing time, personnel information, etc.

• Activation code: If you select the online mode when the device is activated, you need to enter the platform IP and then enter the platform’s current activation code to complete the activation. The activation code is a 12 character alphanumeric string, and is case-insensitive.

• Regulars: Permanent personnel, allowed access by default unless deleted, ruled by cyclical time periods. Generally used for full-time personnel such as employees and in households. Judgment priority: Regulars > visitors.

• Visitors: personnel with temporary access, typically only allowed access within a specified period of time. After the specified timeframe expires, the terminal will automatically delete the person.

• Personnel database: The personnel database stored locally on the terminal, including all personnel delivered from the platform or imported locally.

• Local library: The personnel exist in the local personnel library of the terminal device.

• ID check: Check whether the photo of the ID card and the face photo captured by the holder match.

• Threshold: The facial comparison algorithm will score the result of the image comparison. The threshold serves as the minimum passing score for determining if two images feature the same subject.

• Image quality assessment: The quality of the photo is scored through three aspects: the offset angle of the face, the sharpness of the photo, and whether the face is occluded. These three parameters are used to filter photos which may affect the recognition accuracy.

• Recognition parameter library: an item in personnel details, which is used to specify the threshold used for the specified personnel during facial recognition on the device.

• Access control signal: Wiegand signal format setting for terminal input and output.

• Quick scenario: Liveness detection is deactivated. It is suitable for usage scenarios with a lot of personnel, and high requirements for recognition speed.

• Secure scenario: Live detection is enabled It is suitable for usage scenarios with stricter security requirements.

• Liveness detection: The device assesses whether the identified object is a living body, that is, a real person, as opposed to a printed image.

• Rolling deletion: When the capacity of access records reaches the set upper limit of available disk space, the terminal will automatically delete the earliest records to free up space for new records.

• Authorization list: Under 1:1 comparison mode, after facial image of the snapshot and the ID card are successfully matched, the device will subsequently check whether the card ID number exists in the device’s database. If the ID number exists in the database, the verification succeeds, and fails otherwise.

• ODSL：Allows external developers to embed their application into the recognition process without needing to modify the source code. It combines configuration and external developer’s app to build functional extensions. This process only supports the expansion and embedding of new processes onto existing procedures, and cannot modify existing processes.

10. Appendix

10.1 Serial Port API Development

1. Android devices will need to import the SDK package (com.beeboxes.sdk.jar) to the compileonlylibs directory.

2. The PC client will need to import the serial SDK package (SerialTransport.jar) to the libs directory.

3. The serial demo is executed for the first time, the system will kill the process and cause a crash when the USB read and write permissions are granted. The process can be simply restarted without affecting functionality.

10.2 Required/Optional Items & Restrictions on Device Parameters