26.1 Android™

Since Android™ is a case-sensitive system like UNIX, all RP 1210 files (main INI, vendor INI, and shared object [so]), along with directory names, will be in all lower case letters. The DOS FAT file naming convention will also apply (file names with eight characters in front of the period and three characters after the period).

Due to the sandboxed nature of applications on Android and the complexities surrounding version management and application testing, it will not be the responsibilities of the VDA vendor to create an install for the RP1210 files, only to provide the list of installation files and directory paths to where the files are installed. It is recommended that the default location for installation is on internal storage where possible. This will make the files accessible to only the application that it is bundled with.

1. 26.1.1. Accounts, Groups, Files, and Permissions 

   Because the driver and related INI files are distributed with and installed by the application and are not shared between applications, it is the responsibility of the application to package the files for delivery. Any INI files used by the driver shall be placed isun the root application storage path for iOS™ and Android™.

   One INI that corresponds to the file normally referenced in RP121032.ini should be used for determining device capabilities. Internally used INI files should be named, vendorname_xyz, where xyz are unique names, to avoid file conflicts.

2. 26.1.2. System APIs 
   • Since there is no common "MessageBoX'  function in Android™, all error text from the VDA SO or application executable should be sent to the standard Android™ log functions. These logs can be viewed in the development environment such as using logcat within Android Studio™.
   • There is no need for user environment variables at this point.
3. 26.1.3. API Changes 
   • The most notable of the changes are that the Windows™ call GetPrivateProfileString ()  is not present on an Android device, meaning INI file processing routines must be written.
   • Also, dlopen (), dlsym (),  and dlclose ()  will take the place of the Windows™ LoadLibrary (), GetProcAddress (),  and FreeLibrary ()  calls.
   • Instead of CR/LF (ASCII 0x0D/0x0A) line endings which are seen on DOS/Windows™, the line ending character for INI files will be a single LF character (ASCII 0x0A) commonly called a "newline" character.
   • RP1210 INI section names and variable names are not case sensitive. Application RP1210 INI file parsing can take care of this, just like the Windows™ call GetPrivateProfileString ()  did.
4. 26.1.4. RP1210 SO (Shared Object) Files 

   Where Windows™ had Dynamic Link Libraries (DLL files), Android™ systems have Shared Object files (SO files). The Android™ system has analogous calls to LoadLibrary ()  and GetProcAddress ()  and these will be shown in some code snippets later in this section (see Fig 1dlopen ()  and dlsym ()). 

5. 26.1.5. RP1210 Includes, Type Definitions, and Function Declarations For Android™ 

   The following are the function declarations that are for RP 1210 on Android along with snippets of code showing an application developer how to load ™an SO and get the function pointers from it. There may be additional APIs required to initialize things such as Android Bluetooth™. If required such non-standard APIs must be clearly documented for application developers.

   Fig 1: Software Code

   
6. 26.1.6. Single Application - Multiple Connections 

   Due to the sandboxed nature of applications on Android™ applications, RP 1210 drivers will not be shared across applications and will support the SA/MC operation defined in Section 26.2.  In other words, the first application to gain access to the device shall have exclusive rights to open multiple client connections. If other applications subsequently try to load RP 1210 and attempt to access the device, they shall fail with an "ERR_DEVICE_IN_USE  " error code. It is anticipated that in standard use cases, a single application would make more than one client connection with different protocols in order to send/receive data on multiple buses. MA/MC Multiple Applications/Multiple Connections shall not be considered here as part of this addendum.

7. 26.1.7. Limited Pass-Thru Mode 

   On resource constrained platforms and devices, an application developer should not expect to create applications that process all messages, from all protocols, 100 percent of the time. The developers should design their applications with filters enabled, in order to get satisfactory performance. This is especially true over Bluetooth connected devices. VDA providers are suggested to implement filtering on the device to efficiently utilize the available bandwidth.