[G2 Original Android Development] blastagator:
Realized additional blobs for qseecom:

https://github.com/blastagator/them...mmit/09bc989cdb0db9bc47f7501dbf36be2a155ca168

Also, updated boardconfig since the bacon qseecomd supports TARGET_KEYMASTER_WAIT_FOR_QSEE

https://github.com/blastagator/cm_d...mmit/6ca7cd8835afa57ebec9b47fc56514d87ee95e34

Building now. Not sure if I can test tonight, but fingers crossed, maybe it will work!

No luck. Still the same errors:

12-31 23:22:39.385 2697 2697 I keystore: Found keymaster0 module Keymaster QCOM HAL, version 3
12-31 23:22:39.385 2697 2697 I SoftKeymaster: system/keymaster/soft_keymaster_device.cpp, Line 122: Creating device
12-31 23:22:39.385 2697 2697 D SoftKeymaster: system/keymaster/soft_keymaster_device.cpp, Line 123: Device address: 0xb6b64000
12-31 23:22:39.386 2697 2697 D QCOMKeyMaster: keymaster app is loaded
12-31 23:22:39.386 2697 2697 D QCOMKeyMaster: keymaster app got loaded at attempt number 0
12-31 23:22:39.386 2697 2697 D QSEECOMAPI: : QSEECom_get_handle sb_length = 0x2000
12-31 23:22:39.386 2697 2697 D QSEECOMAPI: : App is not loaded in QSEE
12-31 23:22:39.392 2697 2697 E QSEECOMAPI: : Error::Load image request failed ret = -1, errno = 14
12-31 23:22:39.392 2697 2697 E QSEECOMAPI: : Error::Loading image failed with ret = -1
12-31 23:22:39.393 2697 2697 D QSEECOMAPI: : QSEECom_get_handle sb_length = 0x2000
12-31 23:22:39.393 2697 2697 D QSEECOMAPI: : App is not loaded in QSEE
12-31 23:22:39.393 2697 2697 E QSEECOMAPI: : Error::Cannot open the file /firmware/image/keymaste.mdt
12-31 23:22:39.393 2697 2697 E QSEECOMAPI: : Error::Loading image failed with ret = -1
12-31 23:22:39.393 2697 2697 E QCOMKeyMaster: Loading keymaster app failed
12-31 23:22:39.393 2697 2697 E keystore: Error opening keystore keymaster0 device.
12-31 23:22:39.393 2697 2697 E keystore: keystore keymaster could not be initialized; exiting

Guessing there is some sort of signature check that is matching the expected device to the keymaster firmware file. Unfortunately qseecomapi and keymaster are closed source, so it is kind of a guessing game...

/**
* @brief Open a handle to the QSEECom device.
*
* - Load a secure application. The application will be verified that it is
* secure by digital signature verification.
* Allocate memory for sending requests to the QSAPP
*
* Note/Comments:
* There is a one-to-one relation for a HLOS client and a QSAPP;
* meaning that only one app can communicate to a QSAPP at a time.
*
* Please note that there is difference between an application and a listener
* service. A QSAPP must be loaded at the request of the HLOS,
* and all requests are orginated by the HLOS client.
* A listener service on the otherhand is started during start-up by a
* daemon, qseecomd.
*
* A HLOS application may create mutiple handles to the QSAPP
*
* @param[in/out] handle The device handle
* @param[in] fname The directory and filename to load.
* @param[in] sb_size Size of the shared buffer memory for sending requests.
* @return Zero on success, negative on failure. errno will be set on
* error.
*/
int QSEECom_start_app(struct QSEECom_handle **clnt_handle, const char *path,
const char *fname, uint32_t sb_size);

Perhaps something in one of the .prop files could be changed to trick the app into passing a device check, but again, this is all very speculative.