Android AccountManager - Handling the deprecation of removeAccount() in API 22
February 27, 2018The Situation
In Android API level 22 (Lollipop MR1), the method
AccountManager.removeAccount(Account, AccountManagerCallback<Boolean>, Handler) // old method
was deprecated. The SDK documentation says to instead use this method,
AccountManager.removeAccount(Account, Activity, AccountManagerCallback<Bundle>, Handler) // new method
added in the same API level.
AccountManager.removeAccount()
is a method used to remove an account tracked
by the Android OS for your app, and needs to be called when the user logs out of
their account in your app.
You’ll want to be a prudent developer and migrate away from deprecated methods,
but if your minSdkVersion
is less than 22, you’ll need to resolve this
seemingly large discrepancy between these two AccountManager
methods. To
accomplish this, we’ll start with a draft of a utility method that will call one
or the other depending on what version of Android your app is running in, with
an argument signature that matches the new version of the removeAccount()
method.
public static void removeAccount(
Account account,
Activity activity,
final AccountManagerCallback<Bundle> callback,
Handler handler
) {
AccountManager accountManager = AccountManager.get(activity);
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP_MR1) {
// API 22 and above
accountManager.removeAccount(account, activity, callback, handler);
} else {
// API 21 and below
accountManager.removeAccount(account, /* AccountManagerCallback<Boolean> */, handler);
// we need to figure out what to do for the second argument
}
}
The Discrepancy
The big difference between these two methods is the
AccountManagerCallback<boolean></boolean>
and AccountManagerCallback<bundle></bundle>
arguments, both callbacks that asynchronously return an
AccountManagerFuture<!--?-->
. In the case of the former,
new AccountManagerCallback<Boolean>() {
@Override
public void run(AccountManagerFuture<Boolean> future) {
// get the success status of the account manager operation from `future`
Boolean result = future.getResult();
// do something with the result...
}
}
How do we go from this Boolean
to a Bundle
? The answer lies in what the new
removeAccount()
method returns in its AccountManagerCallback<bundle></bundle>
callback. If you were to execute the new removeAccount()
method, you would
find that the AccountManagerCallback<bundle></bundle>
asynchronously returns a Bundle
that contains AccountManager.KEY_BOOLEAN_RESULT
and a Boolean
as a key/value
pair. The Boolean
value returned indicates the success or failure of the
account removal operation. We can take the Boolean
result from the old
callback and adapt it to the new callback.
public static void removeAccount(
Account account,
Activity activity,
final AccountManagerCallback<Bundle> callback,
Handler handler
) {
AccountManager accountManager = AccountManager.get(activity);
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP_MR1) {
// API 22 and above
accountManager.removeAccount(account, activity, callback, handler);
} else {
// API 21 and below
accountManager.removeAccount(
account,
new AccountManagerCallback<Boolean>() {
@Override
public void run(final AccountManagerFuture<Boolean> future) {
// call our AccountManagerCallback<Bundle> callback and put the Boolean result from `future`
// into a Bundle in the form that the system is expecting
callback.run(new AccountManagerFuture<Bundle>() {
@Override
public Bundle getResult()
throws OperationCanceledException, IOException, AuthenticatorException
{
Bundle result = new Bundle();
result.putBoolean(AccountManager.KEY_BOOLEAN_RESULT, future.getResult());
return result;
}
});
}
},
handler
);
}
}
The AccountManagerCallback<Boolean>
interface has a few other methods that
also need to be implemented and adapted to an AccountManagerCallback<Bundle>
callback.
new AccountManagerCallback<Boolean>() {
@Override
public void run(final AccountManagerFuture<Boolean> future) {
if (callback == null) {
return;
}
callback.run(new AccountManagerFuture<Bundle>() {
@Override
public boolean cancel(boolean mayInterruptIfRunning) {
return future.cancel(mayInterruptIfRunning);
}
@Override
public boolean isCancelled() {
return future.isCancelled();
}
@Override
public boolean isDone() {
return future.isDone();
}
@Override
public Bundle getResult()
throws OperationCanceledException, IOException, AuthenticatorException
{
Bundle result = new Bundle();
result.putBoolean(AccountManager.KEY_BOOLEAN_RESULT, future.getResult());
return result;
}
@Override
public Bundle getResult(long timeout, TimeUnit unit)
throws OperationCanceledException, IOException, AuthenticatorException
{
Bundle result = new Bundle();
result.putBoolean(AccountManager.KEY_BOOLEAN_RESULT, future.getResult(timeout, unit));
return result;
}
});
}
}
We’ve taken the results of the old-style callback and “forwarded” them to the
new-style callback. Since the future.getResult()
method can throw
OperationCanceledException
, IOException
, and AuthenticatorException
, we’ll
“forward” them by passing them up to be handled by the new-style callback.
Putting it all together
Putting all of this together results in a utility method that resolves the discrepancy between the old and new way of removing an account from the system.
/*
* In API 22 (LOLLIPOP_MR1),
* AccountManager.removeAccount(Account, Activity, AccountManagerCallback<Bundle>, Handler) was added, and
* AccountManager.removeAccount(Account, AccountManagerCallback<Boolean>, Handler) was deprecated.
*
* To resolve this when running on a pre-22 device, call the old .removeAccount(), get the Boolean result,
* put it in a Bundle using key AccountManager.KEY_BOOLEAN_RESULT,
* then call AccountManagerCallback<Bundle> callback.run() with a new AccountManagerFuture<Bundle>
* that returns this Bundle.
*/
public static void removeAccount(
@NonNull Account account,
@NonNull Activity activity,
@Nullable final AccountManagerCallback<Bundle> callback,
@Nullable Handler handler
) {
AccountManager accountManager = AccountManager.get(activity);
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP_MR1) {
accountManager.removeAccount(account, activity, callback, handler);
} else {
//noinspection deprecation - we don't need our IDE to warn us that this is deprecated
accountManager.removeAccount(
account,
new AccountManagerCallback<Boolean>() {
@Override
public void run(final AccountManagerFuture<Boolean> future) {
if (callback == null) {
return;
}
callback.run(new AccountManagerFuture<Bundle>() {
@Override
public boolean cancel(boolean mayInterruptIfRunning) {
return future.cancel(mayInterruptIfRunning);
}
@Override
public boolean isCancelled() {
return future.isCancelled();
}
@Override
public boolean isDone() {
return future.isDone();
}
@Override
public Bundle getResult()
throws OperationCanceledException, IOException, AuthenticatorException
{
Bundle result = new Bundle();
result.putBoolean(AccountManager.KEY_BOOLEAN_RESULT, future.getResult());
return result;
}
@Override
public Bundle getResult(long timeout, TimeUnit unit)
throws OperationCanceledException, IOException, AuthenticatorException
{
Bundle result = new Bundle();
result.putBoolean(AccountManager.KEY_BOOLEAN_RESULT, future.getResult(timeout, unit));
return result;
}
});
}
},
handler
);
}
}
You can find this code in this Github gist.
Now when you need to remove an account, you can just call
removeAccount(
account,
activity,
new AccountManagerCallback<Bundle>() {
@Override
public void run(AccountManagerFuture<Bundle> future) {
try {
Bundle result = future.getResult();
boolean success = result.getBoolean(AccountManager.KEY_BOOLEAN_RESULT);
if (success) {
// the account was successfully removed
} else {
// failed to remove the account
}
} catch (OperationCanceledException | IOException | AuthenticatorException e) {
// something went wrong
}
}
},
null
);
Let’s do it with Java 8 Lambdas
If you’re using the latest version of the Android Gradle plugin (as of this
writing) in your build.gradle
file
buildscript {
...
dependencies {
classpath 'com.android.tools.build:gradle:3.0.1'
...
}
}
and using Java 8 source compatibility
compileOptions {
sourceCompatibility JavaVersion.VERSION_1_8
targetCompatibility JavaVersion.VERSION_1_8
}
then you can write the same method using lambdas.
public static void removeAccount(
@NonNull Account account,
@NonNull Activity activity,
@Nullable final AccountManagerCallback<Bundle> callback,
@Nullable Handler handler
) {
AccountManager accountManager = AccountManager.get(activity);
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP_MR1) {
accountManager.removeAccount(account, activity, callback, handler);
} else {
//noinspection deprecation - we don't need our IDE to warn us that this is deprecated
accountManager.removeAccount(
account,
future -> {
if (callback == null) {
return;
}
callback.run(new AccountManagerFuture<Bundle>() {
@Override
public boolean cancel(boolean mayInterruptIfRunning) {
return future.cancel(mayInterruptIfRunning);
}
@Override
public boolean isCancelled() {
return future.isCancelled();
}
@Override
public boolean isDone() {
return future.isDone();
}
@Override
public Bundle getResult()
throws OperationCanceledException, IOException, AuthenticatorException {
Bundle result = new Bundle();
result.putBoolean(AccountManager.KEY_BOOLEAN_RESULT, future.getResult());
return result;
}
@Override
public Bundle getResult(long timeout, TimeUnit unit)
throws OperationCanceledException, IOException, AuthenticatorException {
Bundle result = new Bundle();
result.putBoolean(AccountManager.KEY_BOOLEAN_RESULT, future.getResult(timeout, unit));
return result;
}
});
},
handler
);
}
}
Let’s do it in Kotlin
This utility method is a perfect candidate for a
Kotlin extension method on AccountManager
.
/*
* In API 22 (LOLLIPOP_MR1),
* AccountManager.removeAccount(Account, Activity, AccountManagerCallback<Bundle>, Handler) was added, and
* AccountManager.removeAccount(Account, AccountManagerCallback<Boolean>, Handler) was deprecated.
*
* To resolve this when running on a pre-22 device, call the old .removeAccount(), get the Boolean result,
* put it in a Bundle using key AccountManager.KEY_BOOLEAN_RESULT,
* then call AccountManagerCallback<Bundle> callback.run() with a new AccountManagerFuture<Bundle>
* that returns this Bundle.
*/
fun AccountManager.removeAccount(
account: Account,
activity: Activity? = null,
handler: Handler? = null,
callback: (AccountManagerFuture<Bundle>) -> Unit
) {
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP_MR1) {
removeAccount(account, activity, callback, handler)
} else {
@Suppress("DEPRECATION")
removeAccount(
account,
{ future ->
callback(object : AccountManagerFuture<Bundle> {
override fun cancel(mayInterruptIfRunning: Boolean): Boolean {
return future.cancel(mayInterruptIfRunning)
}
override fun isCancelled(): Boolean {
return future.isCancelled
}
override fun isDone(): Boolean {
return future.isDone
}
override fun getResult(): Bundle {
val bundle = Bundle()
bundle.putBoolean(AccountManager.KEY_BOOLEAN_RESULT, future.getResult())
return bundle
}
override fun getResult(timeout: Long, unit: TimeUnit): Bundle {
val bundle = Bundle()
bundle.putBoolean(AccountManager.KEY_BOOLEAN_RESULT, future.getResult(timeout, unit))
return bundle
}
})
},
handler
)
}
}
You can find this code in this Github gist. The Kotlin version is courtesy of my co-workers Josh Friend and Scott Schmitz.
Looking for more like this?
Sign up for our monthly newsletter to receive helpful articles, case studies, and stories from our team.
Kotlin Multiplatform
July 14, 2022A brief look at Kotlin Multiplatform Mobile, a newer cross-platform mobile application framework.
Read moreBusiness Model Canvas: Helping business leaders create meaningful digital products
January 17, 2024When it comes to custom software, it’s easy to feel stuck between needing to deliver value quickly, while also ensuring meaningful, long-lasting results. Learn why the Business Model Canvas can help you identify the right digital product for your business needs.
Read moreWhat to know about the cost of custom app development
January 10, 2024We hear a lot of ideas for apps at MichiganLabs. People from large enterprises and small startups, located all over the world, call us to explore their mobile and web-based application ideas, and one of the first questions they ask is: How much is this app going to cost?
Read more