Let me try to answer your questions.
Forcing an auto sign-in for a given account: CredentialManager (and its predecessor One Tap APIs on which it relies) does not provide a method to auto sign-in if more than one account on the device has the sign-in grants (I.e. user had signed-in using those accounts), and this is by design, In your case, you mentioned that it is causing troubles for you for a background sync with Google drive. I am not sure why for a sync with Google Drive, you would need to sign the user in each time. Signing in is an authentication process and that on its own is not going to enable you gain access to the user's Drive storage; you would need an Access Token, so I suppose after authentication of the user, you're calling the preferred Authorization APIs with the appropriate scopes to obtain an access token. If you want continuous background access, the standard approach is to get an Auth Code and then exchange that for a refresh token so whenever your access token expires, you can refresh that. This usually requires (in the sense of a very strong recommendation) a back-end on your side to keep the refresh token safe. An alternate approach that you can use on Android is to keep the email account of the user after a successful sign-in, call the Authorization APIs as mentioned above and then in subsequent attempts, call the same Authorization API but pass the account and you will get a Access Token (possibly a refreshed one if the old one is expired) without any UI or user interaction, as long as the user hasn't revoked the Drive access.
CredentialManager#clearCredentialState() behaves the same way as the old signOut().
Could you explain the flow and the error you get in that scenario? In general, revoking access to an app by user amounts to sign out + removing the previously granted permissions/grants. After such action, user should still be able to sign into the app as a new user, i.e. they should see the consent page to share email, profile and name with the app. Note that there is a local cache on the Android device that holds ID Tokens that are issued during a successful sign-in for the period that they are still valid (about an hour if I am not mistaken). When you go to the above-mentioned settings page to remove an apps permission, that state doesn't get reflected on the device: an immediate call may return the cached ID Token but this shouldn't cause a failure in sign-in. So please provide more info on the exact steps, the exact error that you (as a developer) and a user sees in that flow; with that extra information, I might then be able to help.