This way, we run the self test when extracting a CSR on the factory
line by default. This will ensure that devices producing bad payloads
will be more likely to be caught earlier in the manufacturing flow.
Test: ran tool devices with V2 and V3 HALs
Bug: 284098419
Change-Id: I79b50da7f86da50ebcfe18caf06046f1a39c6e81
The data format changed a bit, and the fingerprint needs to be included
at the end of the CSRv3 data. Make sure to include that, else the RKP
server rejects the payload.
Test: run tool + upload output
Test: rkp_factory_extraction_lib_test
Change-Id: I5a13b21e65c64f19b9417a7d1e169710867e7a8f
Self test mode gets a test CSR and validates it.
Test: rkp_factory_extraction_tool --self_test
Test: atest VtsHalRemotelyProvisionedComponentTargetTest
Bug: 239839050
Change-Id: Ib4b0221ffcf56b60ded1ac2a1f85eddb77729cbf
This way, partners doing testing can see if they are getting bad device
info before they try to upload it to the backend.
This also acts as a check on the factory line, in case a device is
misprovisioned or defective, it can be discoverd earlier in the
manufacturing process (as CSRs tend to be uploaded at the very end).
Test: atest VtsHalRemotelyProvisionedComponentTargetTest
Test: rkp_factory_extraction_tool
Bug: 239838563
Change-Id: I8da97a9740cccb3263d21b07ba9d678513a337c8
This way, we can unit test the library in preparation for up-coming
changes that will verify the outputs. This will serve as an extra
layer of checking for factory lines, where they want to be extra
sure that a device is outputing correct information at various stages
of the pipe.
Bug: 239838563
Test: rkp_factory_extraction_lib_test
Change-Id: I018194673820d2b31c18d30057aa533cb4fe090e
