android--Lock launch-native browser boot-boot provision

Some time ago did a function, is to lock the main launch, the machine can only run our definition of launch, did not pay attention to the impact,

The recent discovery was that the native browser could not be started because the lock filter was added to AMs.

I was depressed, how to think of it is strange, this completely unrelated two things how can affect ~ here record

Writing is not easy, reproduced please specify the source: http://blog.csdn.net/jscese/article/details/41015941

Lock main Launch

The process principle of starting the Android system launch can refer to the home launch in the android--startup process

This online method is more, the most common is to modify the original category_home variable or add a new variable to do the filter conditions, need to modify the source of the category_home in the place.

For example, I changed category_home in/frameworks/base/core/java/android/content/intent.java to:

public static final String category_home = "Android.intent.category.JSCESE_HOME";

This is used elsewhere in the source code. Category_homeVariables can not be moved, the overall compilation needs to use Make Update-apiUpdate the API.

Then just put in the Androidmanifest.xml file that we want to be the launch apk:

<category android:name= "Android.intent.category.HOME"/>//changed to <category android:name= " Android.intent.category.JSCESE_HOME "/>

So only the definition of Andorid.intent.category.JSCESE_HOME This category of launch can be the system as HOME launch start up!

Looks like there is no problem ~

Native browser start

As described above can be normally locked in our designated launch, but the problem is ~, when the start of the browser is directly exited, the launch of other apk, or use other browsers can be normal operation,

I found out that the reason for the exit was in Browseractivity.java:

Private Boolean shouldignoreintents () {...  Ignore |= mkeyguardmanager.inkeyguardrestrictedinputmode ();   This is true! Represents a keyboard lock causing the program to Finishreturn ignore;}

The last track debugging, Windowmanagerservice-->phonewindowmanager-->keyguardviewmediator in:

    /**     * Given The state of the Keyguard, is the input restricted?     * Input is restricted when the keyguard are showing, or when the Keyguard     * were suppressed by a app that disabled the Keyguard or we haven ' t been provisioned yet.     */Public    Boolean isinputrestricted () {    log.d (TAG, "jscese display mshowing = =" +mshowing+ "  " + Mneedtoreshowwhenreenabled+ "  " +!mupdatemonitor.isdeviceprovisioned ());        return Mshowing | | mneedtoreshowwhenreenabled | | !mupdatemonitor.isdeviceprovisioned ();    }

I found !mupdatemonitor.isdeviceprovisioned () ==true！

Traced to the Keyguardupdatemonitor.java:

mdeviceprovisioned = Settings.Global.getInt (                mcontext.getcontentresolver (), Settings.Global.DEVICE_ provisioned, 0)! = 0;

The problem is here, and here we get 0 ~

I went to setting.db to check the device_provisioned in the global table:

SELECT * FROM global where name= ' device_provisioned ';

Sure enough, the value in DB is 0! Query method can refer to: Android--sqlite3 basic command operation

The source of a global search, found in the/packages/apps/provision/src/com/android/provision/defaultactivity.java has such a line:

Settings.Global.putInt (Getcontentresolver (), Settings.Global.DEVICE_PROVISIONED, 1);

horse eggs, I instantly understand the causes and consequences, I see this defaultactivity.java also familiar ... The original is missing this really the first apk ~

Boot provision

This boot apk is generally ignored by many people, this time I also overlooked, the first contact with Android also know this thing, long time no contact to forget ~

This apk is defined as the Android first boot apk, Androidmanifest.xml and general launch:

            <intent-filter android:priority= "1" >                <action android:name= "Android.intent.action.MAIN"/>                <category android:name= "Android.intent.category.HOME"/>                <category android:name= " Android.intent.category.DEFAULT "/>            </intent-filter>

So in fact AMSIn the starthomeactivitylockedWhen you start the home activity, this provision defaultactivityis also being queried,

And because the priority = 1 is higher than the general launch, and is directly started, does not count as many home launch.

Look at this defaultactivity.java:

/** * Application That's sets the provisioned bit, like SetupWizard does. */public class Defaultactivity extends Activity {@Override protected void onCreate (Bundle icicle) {Super.on        Create (Icicle);        Add a persistent setting to allow other apps to know the device has been provisioned.   Settings.Global.putInt (Getcontentresolver (), Settings.Global.DEVICE_PROVISIONED, 1);        Here a status value is set, which is the device_provisioned mentioned above, which means the upgrade is complete, the device is ready ~//Remove this activity from the package manager.        Packagemanager pm = Getpackagemanager ();        ComponentName name = new ComponentName (this, defaultactivity.class); Pm.setcomponentenabledsetting (name, packagemanager.component_enabled_state_disabled,//This is directly from PackageManager        Remove yourself, that is, this activity only initiates such a packagemanager.dont_kill_app);        Terminate the activity.    Finish (); }}

This guide, in addition to setting the ready to complete the flag, shielding themselves out of nothing else to do,

Device_provisioned:

There is said to be set into the setting.db of the global table inside, this flag is very important, like the above is because the keyboard detection this flag is still 0, resulting in the keyboard is locked state, unable to use the browser,

In addition, there are lock screen programs do not lock screen, the home key processing is different; the phone is not going to come in.

In addition, the actions removed from the Packagemanager are saved in the Packages.xml in the/data/system directory.

Also note that you see this activity is used to do the Setup Wizard ~ So some of the first time you need to do some of the operation can be added here to let it start:

There is also directly here directly to query home, and then jump to the specified launch~

Like I said above the kind of locking launch, is because the boot provision missing this boot, so can not start browser, but there are other functional hidden trouble!

The solution is to put this provision androidmanifest.xml in the same way:

<category android:name= "Android.intent.category.HOME"/>//changed to <category android:name= " Android.intent.category.JSCESE_HOME "/>

Intent implicit startup, activity start selection box

When using intent to start the activity implicitly, all the activity that satisfies the condition through the Packagemanager query, if there is more than one satisfies, then will pop up a dialog, let the user choose!

The above mentioned multiple home launch state, want to lock my own launch also for this reason!

Take a rough look at the process:

Generally starting an activity is context.startactivity (intent) and the like, the initial call to/frameworks/base/core/java/android/app/ Contextimpl.java:

    @Override public    void StartActivity (Intent Intent, Bundle options) {        warnifcallingfromsystemprocess ();        if ((Intent.getflags () &intent.flag_activity_new_task) = = 0) {            throw NEW androidruntimeexception (                    " Calling StartActivity () from outside of a Activity "                    +" context requires the Flag_activity_new_task FLAG. "                    + "are this really what do you want?");        }        Mmainthread.getinstrumentation (). Execstartactivity (            getoutercontext (), Mmainthread.getapplicationthread (), NULL,            (Activity) NULL, intent,-1, options);    }

Call the execstartactivity in Instrumentation.java in the same directory, and then call Activitymanagernative.getdefault (). StartActivity (*);

It's obvious that the next step is to call Startacitivity in AMS.

    Public final int startactivity (iapplicationthread caller, Intent Intent, String resolvedtype, IBinder Resul TTo, string resultwho, int requestcode, int startflags, string profilefile, Parcelfiledescriptor Pro FILEFD, Bundle options) {return Startactivityasuser (caller, intent, Resolvedtype, Resultto, resultwho, Requestcode    , Startflags, Profilefile, PROFILEFD, Options, Userhandle.getcallinguserid ()); } public final int startactivityasuser (iapplicationthread caller, Intent Intent, String Resolvedtype, Ibinde R Resultto, string resultwho, int requestcode, int startflags, string profilefile, Parcelfiledescrip        Tor profilefd, Bundle options, int userId) {Enforcenotisolatedcaller ("startactivity"); UserID = Handleincominguser (Binder.getcallingpid (), Binder.getcallinguid (), UserId, False, True, "startacti        Vity ", NULL); return mmainstack.startactivitymaywait (Caller,-1, intent, Resolvedtype, Resultto, resultwho, Requestcode, Startflags, Profilefile, PROFILEFD,    NULL, NULL, options, USERID); }

Call into/frameworks/base/services/java/com/android/server/am/activitystack.java:

Final int startactivitymaywait (iapplicationthread caller, int callinguid, Intent Intent, String Resolvedtype, I Binder Resultto, string resultwho, int requestcode, int startflags, string profilefile, Parcelfilede Scriptor profilefd, Waitresult outresult, Configuration Config, Bundle options, int userId) {... newintent.pu                        TExtra (Heavyweightswitcheractivity.key_new_app, ainfo.packagename);                        Newintent.setflags (Intent.getflags ());  Newintent.setclassname ("Android", HeavyWeightSwitcherActivity.class.getName ()); You can see a series of criteria above, and found that if more than one activity satisfies the condition, a selection activity intent = Newintent is started here. ... int res = St Artactivitylocked (caller, intent, Resolvedtype, Ainfo, Resultto, resultwho, Requestcode, Callingpid, CA Llinguid, Startflags, options, componentspecified, null);... return res;

Can look at the/frameworks/base/core/java/com/android/internal/app/heavyweightswitcheractivity.java:

/** * This activity was displayed when the system attempts to start an Intent for * which there are more than one matching a Ctivity, allowing the user to decide * which to go.  It is not a normally used directly by application developers. */public class Heavyweightswitcheractivity extends activity {    /** the pendingintent of the new activity being launched . */public    static final String key_intent = "INTENT";    /** Set If the caller is requesting a result. */public    static final String Key_has_result = "Has_result";    /** package of the current Heavy-weight app. */public    static final String Key_cur_app = "Cur_app";    /** Task, heavy-weight activity is running in. * * Public    static final String key_cur_task = "Cur_task"; 
   /** package of newly requested Heavy-weight app. */public    static final String Key_new_app = "New_app";    

The notes are very clear-written.

android--Lock launch-native browser boot-boot provision