Develop Reference

DevicePolicyManager.enableSystemApp() method does not work as expected

I'm trying to use enableSystemApp method to activate default system apps after provisioning device with the app that is set to device owner mode.
There are two methods to do this:
1) void enableSystemApp (ComponentName admin, String packageName) - in this case you need to pass package name explicitly as String. It works fine, the app gets enabled.
For example, calling this
devicePolicyManager.enableSystemApp(deviceAdminComponent, "com.google.android.gm");
enables default Gmail client, which is disabled after provisioning.
2) int enableSystemApp (ComponentName admin, Intent intent) - in this case, you need to pass an implicit intent and Android should enable all system apps that match this intent. In addition, this method returns int number of apps that match the intent. And here's the problem - I can't get this method to work, it always returns 0 and doesn't enable anything.
Here's the snippet I'm trying to use:
Intent intent = new Intent();
intent.setAction(Intent.ACTION_MAIN);
intent.addCategory(Intent.CATEGORY_APP_EMAIL);
int i = devicePolicyManager.enableSystemApp(deviceAdminComponent, intent);
It does not work and i == 0 in this case. What am I doing wrong?
Any help is appreciated!

Under the hood, the method that accepts an intent queries to get the list of activities that respond to that intent and then loops through the list passing in the package name string to enable the package. It's similar to doing this:
Intent intent = new Intent();
intent.setAction(Intent.ACTION_MAIN);
intent.addCategory(Intent.CATEGORY_APP_EMAIL);
List<ResolveInfo> infoes = getPackageManager()
.queryIntentActivities(intent, MATCH_DIRECT_BOOT_AWARE | MATCH_DIRECT_BOOT_UNAWARE);
for (ResolveInfo info in infoes) {
devicePolicyManager.enableSystemApp(deviceAdminComponent, info.activityInfo.packageName);
}
Since you are able to enable the app using the package name string, the fault most likely lies in the way the intent is being resolved - which is supported by the fact that it always returns 0.
It is counter-intuitive, but my suspicion is that the application does not resolve the ACTION_MAIN intent because the app is disabled. Have you tried a less generic intent? I would try the following
Intent i;
// #1
// This goes full circle, but I expect it should work
i = getPackageManager().getLaunchIntentForPackage("com.google.an‌​droid.gm")
// #2
i = new Intent(Intent.ACTION_SEND).setPackageName("com.google.android.gm");
// #3
// Generic, but should resolve _all_ email apps - not just the default one.
// The mailto schema filters out non-email apps
i = new Intent(Intent.ACTION_VIEW , Uri.parse("mailto:"));
Option #1 and #2 are more academic. Both require the package name at which point you may as well use the string overload of enableSystemApp. Option #3 is my best guess for something generic that might still work, but it's possible that it still won't work because the app is disabled.
Note: I find it interesting that enableSystemApp only passes the MATCH_DIRECT_BOOT_AWARE and MATCH_DIRECT_BOOT_UNAWARE flags when querying activities that can resolve the intent, because the MATCH_DISABLED_COMPONENTS and MATCH_SYSTEM_ONLY flags seem much more relevant in this situation.

Setup a new user after it's created

From my device owner application, I'd like to create a new user and switch directly to it. For now, I can only create a new user, switch to it but:
it brings me to the keyguard screen, that I need to manually unlock.
then, tells me to setup the newly created user - with firstname, lastname, WIFI settings, and 3 Google usage statistics/reporting options.
I'd like to know if there's a way to programmatically setup the new user and switch directly to it's "session". I'd like to programmatically avoid the "unlock" page et pre-setup the newly created user with name, WIFI settings, but also available apps and security settings.
here's what I do so far :
// init block (in onCreate...)
DevicePolicyManager mDPM = (DevicePolicyManager) this.getSystemService(Context.DEVICE_POLICY_SERVICE);
ComponentName mDeviceAdminRcvr = new ComponentName(this, DeviceAdminRcvr.class);
// in my button "create a new user"
ComponentName profileOwnerComponent = new ComponentName(this, ProfileAdminRcvr.class);
Bundle adminExtras = new Bundle();
UserHandle userHandle = mDPM.createAndInitializeUser(mDeviceAdminRcvr, name, ownerName, profileOwnerComponent, adminExtras);
// TODO : place here missing instructions to provision the user...
mDPM.switchUser(mDeviceAdminRcvr, userHandle);
I couldn't find any documentation on the official Google page about device owner apps or profile apps.
Could anyone help me or point me to useful links ?

As far as I've seen, there is no way to programmatically unlock the screen lock. Even the Smart lock functionnality added in Lollipop will just disable the Key Guard, which means that the "PIN" or "Pattern" will transform into a "Swipe Lock" when a trusted agent unlocks the device. Even in this case, you'll need to manually swipe the screen to unlock the device.
Concerning the second point, it's possible to avoid the "Setup Wizard" proposed the first time you unlock a newly created user. Here's how to do it :
in your ProfileAdminRcvr.java, you'll need to hide the system application called com.google.android.setupwizard. You could do this in the onEnabled() method of your DeviceAdminReceiver's implementation (the one you set for your profile when creating the user).
To complete this, you can disable the "first use hint", by setting the Settings.Secure.SKIP_FIRST_USE_HINTS property.
Here's the code to do it :
public class ProfileOwnerRcvr extends DeviceAdminReceiver {
private DevicePolicyManager mDPM;
private ComponentName mProfileAdminRcvr;
#Override
public void onEnabled(Context context, Intent intent) {
mDPM.setProfileName(mProfileAdminRcvr, "My new user");
// ... setup other things by yourself...
mDPM.setApplicationHidden( mProfileAdminRcvr, "com.google.android.setupwizard", true);
mDPM.setSecureSetting(mProfileAdminRcvr, Settings.Secure.SKIP_FIRST_USE_HINTS, "1");
}

Google updated its demo app to use Android-N preview version, it seems that there will be a flag called DevicePolicyManager.SKIP_SETUP_WIZARD to do part of what you are trying to do (i.e skipping the wizard) in N.

Never get AccountManager.KEY_INTENT from getAuthToken request

On JellyBean device.
I'm following this to request an oauth2 token, e.g.
AccountManager am = AccountManager.get(getActivity());
am.invalidateAuthToken(MY_AUTH_TOKEN_TYPE, null);
am.getAuthToken(aGoogleAccount, MY_AUTH_TOKEN_TYPE, null, this,
new OnTokenAcquired(), new Handler(new OnError()));
and then make the check as per the later code sample:
private class OnTokenAcquired implements AccountManagerCallback<Bundle> {
#Override
public void run(AccountManagerFuture<Bundle> result) {
Bundle bundle = result.getResult();
...
Intent launch = (Intent) bundle.get(AccountManager.KEY_INTENT);
if (launch != null) {
startActivityForResult(launch, 0);
return;
}
}
}
I never get a KEY_INTENT. I understand the following:
There may be many reasons for the authenticator to return an Intent. It may be the first time the user has logged in to this account. Perhaps the user's account has expired and they need to log in again, or perhaps their stored credentials are incorrect. Maybe the account requires two-factor authentication or it needs to activate the camera to do a retina scan. It doesn't really matter what the reason is. If you want a valid token, you're going to have to fire off the Intent to get it.
However, the getAuthToken always results in the permission screen, or login screen, appearing before the code hits the run method at which point the token is valid. I've tried:
Turning on 2 step authentication. Account login is requested before run so always have the token in run.
Changing the password on the server. Again account login is requested before run so always have the token in run.
Don't have the ability to try a retina scan so somewhat at a loss.
EDIT 1 The problem I have is that there may be a circumstance where I will get a KEY_INTENT and so I'd rather test this code path now rather when when it's out in the field.
Thanks in advance.
Peter.

Had a chance to do something similar on a project. This not the exactly the same as your code, and I still say that the callback docs have too many 'maybes' to be certain of how it should work, but if you use this method passing false for notifyAuthFailure, you will get an intent with the re-login screen if you change the password or enable 2FA. This is for ClientLogin, but should work similarly for OAuth 2 (not tested though). Something like:
// using Calendar ClientLogin for simplicity
Bundle authResult = am.getAuthToken(account, "cl", false, null, null).getResult();
if (authResult.containsKey(AccountManager.KEY_INTENT)) {
Intent authIntent = authResult.getParcelable(AccountManager.KEY_INTENT);
// start activity or show notification
}

I think you need to call getResult(), like this:
Intent launch = (Intent)result.getResult().get(AccountManager.KEY_INTENT);

You're using the version of getAuthToken which uses an Activity to invoke the access authorization prompt. That version of getAuthToken does not return an intent since the supplied activity is used to launch the corresponding intent. If you want to manually launch an intent, use the version of getAuthToken that was deprecated in API level 14. See the following for more information:
http://developer.android.com/reference/android/accounts/AccountManager.html#getAuthToken%28android.accounts.Account,%20java.lang.String,%20boolean,%20android.accounts.AccountManagerCallback%3Candroid.os.Bundle%3E,%20android.os.Handler%29

Handling the C2DM error ACCOUNT_MISSING in Android

The registration for C2DM may result in an error ACCOUNT_MISSING. This error must be handled, according to the documentation, in this way "The application should ask the user to open the account manager and add a Google account."
I would like to offer to the user this possibility from the application. I have seen two ways to show this screen:
//Intent
context.startActivity(newIntent(Settings.ACTION_ADD_ACCOUNT).putExtra(Settings.EXTRA_AUTHORITIES, new String[] {?}));
The problem for this solution that the I have tried several EXTRA_AUTHORITIES ("com.google", "com.google.android.gsf, etc) and none of them show anything and if the parameter EXTRA_AUTHORITIES is omitted all the phone account are shown.
//Account manager
AccountManager.get(context).addAccount("com.google", null, null, null, this, new AccountManagerCallback<Bundle>() {
public void run(AccountManagerFuture<Bundle> accountManagerHandle) {
//TODO Handle response.
}
}, null);
}
The problem for this solution is that it requires the permission MANAGE_ACCOUNTS, and the users would probably not like to accept an extra permission just for that.
How would you deal with this situation?

For the EXTRA_AUTHORITIES field you can use "gmail-ls" to show only the Google account selector.
After much googling I found the constant in the android.provider.Gmail source code:
public static final String AUTHORITY = "gmail-ls"
This class is not part of the public API so as a workaround it's a bit fragile :-(.

android: Is it possible to sell add-ons for apps in the Market?

I would like to distribute my app for free, and then sell extra features that can be added-on later. Is it possible to do this?

If you're talking about in-app payment, you should take a look at PayPal, which offers In-App-Payment for Android:
http://www.x.com
https://www.x.com/community/ppx/sdks
If you want to distribute your app via Android Market, you would need to offer each add-on as an invididual app. Probably not a convenient way.

Yes you can do it. There are addons all over the market for the better keyboard app.

You have different ways you can do this, here are two ways I already tried.
1) You could implement all the features in the app and a key app that unlocks this features.
Here is a simple and insecure implementation, the key app and the main app need to be signed with the same key:
public boolean isPackageAvailable(String packageName) {
int sigMatch = getPackageManager().checkSignatures(getPackageName(), packageName);
return sigMatch == PackageManager.SIGNATURE_MATCH;
}
Check MarketEnabler on market-enabler.googlecode.com to see how I used it (not not a secure way but a starting point).
2) You include the plugin app as intent into a subview so it looks like just one app splitted to multiple apk's.
Check http://speakerproximity.googlecode.com where I used it to include the settings view inside the mainview:
....
public class SpeakerProximity extends ActivityGroup {
....
mainLayout.addView(getViewFromIntent("preferences", new Intent(
this, PreferenceScreen.class)));
....
public View getViewFromIntent(String tag, Intent intent) {
/** start an activity inside an ActivityGroup and get the window handler **/
final Window w = getLocalActivityManager().startActivity(tag, intent);
/** extract the view out of the window handler **/
final View wd = w != null ? w.getDecorView() : null;
return wd;
}
...
Note that I extend ActivityGroup and not Activity ;-)