Proposal: Integrated RKP Root Toggle via Shizuku

[shoey63]

​Hi @VisionR1,
​I’ve managed to integrate the RKP (Remote Key Provisioning) registration process for rooted users.
​Currently, users have to run a python script provided by Google to toggle the RKP root status (keymint_register_for_new_root / keymint_unregister_for_new_root). I have implemented a UI-based toggle within the HomeFragment overflow menu that handles this automatically using Shizuku.

​Key highlights of the upcoming PR:

• ​Automatic Root Access: Uses Shizuku to execute the registration commands without requiring a manual terminal.
• Reflection-Based Logic: I’ve used reflection for Shizuku's newProcess to keep the implementation clean.
• ProGuard/R8 Ready: I've already tested the minified release build and included the necessary -keep rules to ensure the reflection doesn't break in production.
• Non-Intrusive UI: Added as a simple toggle in the existing menu, keeping the main interface clean.

​I’ve verified the functionality on my own device (it successfully triggers the registration toasts and updates the system state). I’ll be submitting the Pull Request shortly.
I'll also drop the CI build on XDA for interested user until you have a chance to merge and update translations. I realise you don't have a qualifying device, but here is the link to the build.
https://github.com/shoey63/KeyAttestation/actions/runs/23290549402

[VisionR1]

​Hi @VisionR1,​I’ve managed to integrate the RKP (Remote Key Provisioning) registration process for rooted users.​Currently, users have to run a python script provided by Google to toggle the RKP root status (keymint_register_for_new_root / keymint_unregister_for_new_root). I have implemented a UI-based toggle within the HomeFragment overflow menu that handles this automatically using Shizuku.

​Key highlights of the upcoming PR:

• ​Automatic Root Access: Uses Shizuku to execute the registration commands without requiring a manual terminal.
• Reflection-Based Logic: I’ve used reflection for Shizuku's newProcess to keep the implementation clean.
• ProGuard/R8 Ready: I've already tested the minified release build and included the necessary -keep rules to ensure the reflection doesn't break in production.
• Non-Intrusive UI: Added as a simple toggle in the existing menu, keeping the main interface clean.

​I’ve verified the functionality on my own device (it successfully triggers the registration toasts and updates the system state). I’ll be submitting the Pull Request shortly. I'll also drop the CI build on XDA for interested user until you have a chance to merge and update translations. I realise you don't have a qualifying device, but here is the link to the build. https://github.com/shoey63/KeyAttestation/actions/runs/23290549402

Very nice.

Yeah, unfortunately can't test it, my device too old.

So, after this PR, the Key Attestation, will need root access?

[shoey63]

Shizuku needs root access, not the app. Then Shizuku ask for the app to allow access.

[VisionR1]

Oh, i know that.

I got confused, because Shizuku works and without root.

But for full usage need root.

[shoey63]

The app uses a few lines of kotlin to do the pm commands which require root. Much better than trying to import python and dependencies which would make the app 50 to 100 MB.
Also without root you can't clear the RPK key cache with this command after unregistering.
$ su -c "pm clear com.google.android.rkpdapp"
You would have to do a factory reset (as documented by Google) or be stuck with the new RPK root.

[VisionR1]

Yeah, much better.

Understand.

Thanks again for all this new features.

[shoey63]

Ok PR done. Obviously failing to build until you merge because of needing your signature

[shoey63]

Some changes to the PR

• Root is NO LONGER required for this feature. Because we shifted the pm clear execution to Shizuku rather than relying on su -c, non-rooted users can safely toggle their RKP state and clear the stuck daemon cache without fear of bricking their attestation state or needing a factory reset.

• Added a "Dump RKP Chains" utility to the overflow menu (requested by @zgfg on XDA)

- - - - - -

[zgfgNew]

Can you hardcore the newer status, from Mar 16 instead of the Feb 27 status

Also, that app caches the last, latest downloaded status list and use it then instead of the hard coded one

[zgfgNew]

I'm just commenting what I see when comparing the older version v2.00 vvb2060#50 with the newer, latest available for download, the Action build vvb2060#57:

Running KA app from the stock phone with no root.
Hence KA app, neither v2.00 can use root permission for getting the Revocation list

v2.00:= Action build vvb2060#50: I even don't enable Shizuku, KA app shows Revolution l(status) list date Mar 16

Newer Action build vvb2060#57, Shizuku started, Shizuku enabled in KA app, but KA app shows red-crossed, the older (default/hardcoded) Revocation list from Feb 27

[shoey63]

I'm just commenting what I see when comparing the older version v2.00 vvb2060#50 with the newer, latest available for download, the Action build vvb2060#57:

Running KA app from the stock phone with no root. Hence KA app, neither v2.00 can use root permission for getting the Revocation list

v2.00:= Action build vvb2060#50: I even don't enable Shizuku, KA app shows Revolution l(status) list date Mar 16

Newer Action build vvb2060#57, Shizuku started, Shizuku enabled in KA app, but KA app shows red-crossed, the older (default/hardcoded) Revocation list from Feb 27

See if you can replicate any of these issues in my fork
https://github.com/shoey63/KeyAttestation/releases/tag/rpk-reg_dump

[shoey63]

@zgfgNew
​You actually made a great catch regarding the hardcoded list—the bundled fallback file was out of date, so I just submitted a separate PR to update it to March 17th.
​[edit]....
Fall back to hard coded CRL after updating from action build 52 solved in PR #14
....[edit]

[zgfgNew]

Thanks, I installed now Action build #66 and it says it had fetched (by the Last Valid header) the yesterday's 19:48:00 GMT Revocation list