This will seem like a strange question.
I'm helping a vendor who distributes a Kiosk mode app solve a problem that may be happening after a Kryptonite error report from a corrupt cryptohome. Is there a way to either (a) forcibly corrupt a cryptohome, or (b) delete a cryptohome without uninstalling the kiosk mode app?
Here's my thought process:
The application tries to disable accessibility mode features as the kiosk app launches. Normally, this works fine. If I have, for example, highlight cursor turned on, it gets disabled as the kiosk mode app launches, and is re-enabled at the login screen when the kiosk mode app exits.
I've seen the kiosk mode app fail to disable accessibility settings, though. And on a device where it fails, it continues to fail (as far as I can tell) until the device is powerwashed, forcing a reinstall of the kiosk mode app.
On at least one of my devices, the problem seemed to "start" after the cryptohome became corrupt, and the kiosk mode app failed to launch with the beloved Kryptonite message.
There was a discussion in years past about having Chromium automatically create a new cryptohome for Kiosk mode apps. That seems to be happening.
My expectation/curiosity/concern is that this app is probably writing a file to its cryptohome in the installer, and assuming that it's always there. Probably some form of INI file -- and like most good code, it can launch just fine without the ini file. But I'm betting the ini file includes the info to raise the flags disabling accesssibility mode.
And if that ini file is only written by the installer, and there's no code check to see if the cryptohome got blanked because of corruption, it never gets recreated.
Unfortunately, I'm not dealing directly with the apps development team, but reaching them via their technical support team layers...
I haven't mentioned the app by name because it's part of a secure delivery platform used with K-12 and college students, who can sometimes be very creative at finding work-arounds for restrictions....