Allow library consumer to choose whether to enable Android StrongBox

[luckyrat]

Given the earlier concern regarding the reliability of StrongBox on some physical devices (#76), but entirely unclear information on which devices, I still feel that it might be too early to enable StrongBox across the board.

This library still does so, and presumably has had very few or zero issues related to these device bugs. My current fork does not use StrongBox.

As part of the fork consolidation efforts in issue #137, I would like this PR to be merged so that:

1. Existing users of this library see no immediate difference (backwards compatible).
2. Developers migrating from my fork (like me) can choose to either enable StrongBox or retain the disabled state.
3. Migrations to/from a StrongBox backed store can be orchestrated by developers if/when required.
4. Developers will be able to quickly change whether they use StrongBox, perhaps based upon real world feedback from users with devices that crash when it is enabled, or just as a security enhancement when all physical devices with implementation bugs are no longer in active use.
5. Developers could even choose to decide upon the StrongBox feature via an exclude list of known bad devices, if such details ever become apparent to them.
6. Control of the option could potentially be exposed as a debug feature for app users to toggle if advised that production crashes or data loss may be caused by the use of the Secure Enclave.

[gemini-code-assist]

Summary of Changes

Hello @luckyrat, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a new configuration option for Android StrongBox usage, allowing library consumers to explicitly enable or disable it. This change addresses concerns about StrongBox reliability on certain devices while maintaining backward compatibility and providing flexibility for developers to manage key storage based on their needs and device-specific feedback.

Highlights

• Configurable StrongBox Usage: A new "androidUseStrongBox" boolean parameter has been added to InitOptions (Kotlin) and StorageFileInitOptions (Dart) to give developers explicit control over whether StrongBox is utilized for key storage on Android devices.
• Conditional KeyStore Configuration: The underlying CryptographyManager now respects the "androidUseStrongBox" setting, ensuring StrongBox is only used if both the device supports it and the developer has opted in.
• Flutter Integration and Example: The Flutter plugin layer has been updated to pass this new option, and the example application demonstrates how to disable StrongBox, showcasing the new flexibility.
• Enhanced Documentation: Comprehensive documentation has been added for the "androidUseStrongBox" parameter, detailing its purpose, implications (e.g., TEE vs. Secure Element), and the rationale behind its introduction.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces an option to disable Android's StrongBox feature, addressing concerns about its reliability on certain devices. The changes are well-structured, adding the androidUseStrongBox option across the Dart and Kotlin layers, with good documentation and updates to the example app. The default is set to true for backward compatibility.

I've found one potential issue regarding the parsing of this new option on the native Android side, which could lead to a crash if the option is not provided. I've included a suggestion to make the implementation more robust.

[gemini-code-assist]

The direct cast as Boolean will throw a TypeCastException if the androidUseStrongBox key is missing from the options map. To make the native API more robust, it's safer to handle this case by using a safe cast and providing a default value. This will prevent potential crashes.

Note that authenticationRequired and androidBiometricOnly have the same potential issue.

Suggested change

	androidUseStrongBox = it["androidUseStrongBox"] as Boolean,
	androidUseStrongBox = it["androidUseStrongBox"] as? Boolean ?: true,