migrate brapi token management to accountmanager

[trife]

Description

Closes #205

Change Type

• ADDITION (non-breaking change that adds functionality)
• CHANGE (fix or feature that alters existing functionality)
• FIX (non-breaking change that resolves an issue)
• OTHER (use only for changes like tooling, build system, CI, docs, etc.)

Release Note

BrAPI tokens are now managed in Android system settings

[trife]

Other apps call:

val am = AccountManager.get(context)
val accounts = am.getAccountsByType("org.phenoapps.brapi")
am.getAuthToken(accounts[0], "access_token", null, activity, callback, null)

[kamathprasad9]

This works great!

If the user tries to login using two different accounts for the same server, the most recent token is saved - and I expect the workflow to be this way.

In addition to the changes mentioned, the BrapiAccountHelper and BrapiAuthenticator can be migrated to phenolib in the future. But regardless, this is working as intended

[kamathprasad9]

(these exact changes will only work from within the Field Book repository. to migrate to phenolib, might need to write it in a bit different way)
This works, but can instead write it something like

@Singleton
class BrAPIAccountManagerUtil @Inject constructor(
    @ApplicationContext private val context: Context,
    private val preferences: SharedPreferences,
) {

That way, you can also use the preferences within this class instead of having to create the object every time.

Usage in other places

@Inject
BrAPIAccountManagerUtil accountManagerUtil;

[chaneylc]

First, it seems credential manager is the modern approach to account management; although it seems this would require users to have a google account.
https://developer.android.com/identity/sign-in/credential-manager-siwg

After reviewing the documentation for account manager, I think we are doing a few things incorrectly.
https://developer.android.com/reference/kotlin/android/accounts/AccountManager

0. "This class provides access to a centralized registry of the user's online accounts. The user enters credentials (username and password) once per account, granting applications access to online resources with "one-click" approval. " I think this is a big missing piece, we need a list of registered accounts in the brapi settings to easily switch between, current management actually deletes accounts when logging out (see below).

1. Setting the authentication to be exported allows any other installed app to access to the service. It's probably best to setup a signature based permission for this: https://developer.android.com/privacy-and-security/risks/access-control-to-exported-components so only our registered apps can reuse access tokens

2. Account Manager tokens are never invalidated (or checked if they are working), potentially causing various stale token issues.

3. Logging out (and various other code) removes the account from account manager.

4. After removing the brapi account from the system settings, I could still use the token within the app

5. response from add account is ignored, what happens when it fails or there exist multiple accounts for a single server?

6. I expect any external usage of this to not work, as the AccountAuthenticatorResponse handshake is never completed:
   https://developer.android.com/reference/android/accounts/AbstractAccountAuthenticator

[chaneylc]

I like the new compose UI

• settings flash before hiding when navigating to brapi settings page
• error shows when checking brapi compatibility chip for some servers (I see that it does work for some other servers like cassavabase), this does not cause a crash
• after auth from add account/OS settings it leads to a blank white screen in field book but the account is added
• Manual Input / Scan config could be combined in the add account stepper (full screen compose activity would be nice here)
• BaseBrapiAccountDialog* class hierarchy is a little odd, it should use a view model and a UI State object to persist UI across lifecycle changes. I think a cleaner approach would be to implement it as one stepper within the add account activity, with a view model.
• not confident in the mixed handling of extras/prefs it seems extras are sent to brapi auth from add account but will be dropped on the oauth intent call since that intent doesn't populate the extras, which may lead to using current preferences instead of original sent extras
• editing an account seems to actually add new accounts
• suspicious usage of addAccountExplicitly in BrapiAccountHelper when there are duplicate account display names, not entirely certain of the side effects of this but could it overwrite an existing accounts user data that has the same display name?
• double-check new permission