SetupWizard, the provisioned bit, and the startup sequence: an idea.
Jean-Baptiste Queru
can work in AOSP without disrupting the way Google's SetupWizard
works.
On devices that have the Google apps, the first user-visible
application that runs is SetupWizard, The point of SetupWizard is to
allow or force the user to set up a Google account for their device,
along with a few other Google-specific settings.
The part where the user is forced to set up a Google account is the
relevant one here: there is some support in the system to prevent the
user from "escaping" from SetupWizard. All those behaviors are
controlled by a boolean flag called the "privisioned" flag, which is
set by SetupWizard when it completes. Those behaviors are: receiving
phone calls, receiving SMS, pressing the home key, locking the device,
and a few other small things like controlling what is displayed in the
"power" menu).
The problem we're facing in AOSP is that the provisioned bit is
necessary for proper operation of Android, but none of the AOSP code
sets it "out of the box". More frustrating has been the fact that the
operation of the provisioned bit in AOSP should not interfere with the
proper operation of a SetupWizard (Google's or anybody else's).
The key here is to see how SetupWizard is launched:
SetupWizard declares itself as a Home app, with a higher priority than
the regular Home app: you can see a very similar setup on line 27
here: http://android.git.kernel.org/?p=platform/development.git;a=blob;f=apps/SdkSetup/AndroidManifest.xml;h=966eeb106ce7db2804ee7974168762b68b6cd45e;hb=HEAD#l27
When the system gets to a point where it should display "the" Home
app, it uses the standard intent-filter mechanism to do it. With the
"real" home app being declared with the default priority and
SetupWizard being declared at a higher priority, the system launches
SetupWizard. When SetupWizard completes, it disables itself from the
package manager with code similar to line 49 at
http://android.git.kernel.org/?p=platform/development.git;a=blob;f=apps/SdkSetup/src/com/android/sdksetup/DefaultActivity.java;h=56f43a46157304fad26eceef88dde7474fcb30fb;hb=HEAD#l49
and exits. At that point, the system knows it needs to display a Home
app, does the intent-filter dance again, and only finds the "real"
Home app and launches it.
My idea is to use the exact same mechanism to split the pre-Home
startup sequence into several steps, by using different apps each
registered as Home with different priorities: SetupWizard could
register itself with the highest priority of the lot, and would
therefore run first if it's present. Next would come a "Provision"
app, which would in in AOSP, and which would set the provisioned bit,
disable itself and exit right away, the way SdkSetup does it. Finally,
there'd be the "real" Home.
So, on devices with a SetupWizard, it would run first, with the
locking still in place. It'd then fall into Provision, and into Home,
and the existing Google behavior would work fine. Notice that
SetupWizard doesn't need to set the provisioned bit, which simplifies
the task for people trying to write their own.
On devices without a SetupWizard, it would start directly with
Provision, and then fall into home, and the device would be usable.
Am I missing something obvious?
JBQ
--
Jean-Baptiste M. "JBQ" Queru
Software Engineer, Android Open-Source Project, Google.
Questions sent directly to me that have no reason for being private
will likely get ignored or forwarded to a public forum with no further
warning.
Mark Murphy
> My idea is to use the exact same mechanism to split the pre-Home
> startup sequence into several steps, by using different apps each
> registered as Home with different priorities: SetupWizard could
> register itself with the highest priority of the lot, and would
> therefore run first if it's present. Next would come a "Provision"
> app, which would in in AOSP, and which would set the provisioned bit,
> disable itself and exit right away, the way SdkSetup does it. Finally,
> there'd be the "real" Home.
Does the "provisioned" bit ever get unset?
If not, why not just have Home set it (versus a separate one-time
Provision app)? Or will that cause problems with alternative home apps?
> Am I missing something obvious?
Other than the above, and assuming your assessment that AOSP does not
need anything else from SetupWizard holds true, your logic seems sound.
But, then again, I'm a SetupWizard n00b...
--
Mark Murphy (a Commons Guy)
http://commonsware.com | http://twitter.com/commonsguy
Looking for Android opportunities? http://wiki.andmob.org/hado
Jean-Baptiste Queru
On Sun, Sep 27, 2009 at 9:05 AM, Mark Murphy <mmu...@commonsware.com> wrote:
>
> Jean-Baptiste Queru wrote:
>> My idea is to use the exact same mechanism to split the pre-Home
>> startup sequence into several steps, by using different apps each
>> registered as Home with different priorities: SetupWizard could
>> register itself with the highest priority of the lot, and would
>> therefore run first if it's present. Next would come a "Provision"
>> app, which would in in AOSP, and which would set the provisioned bit,
>> disable itself and exit right away, the way SdkSetup does it. Finally,
>> there'd be the "real" Home.
>
> Does the "provisioned" bit ever get unset?
partial fix for that is to have the standard Home app set the bit when
it starts, but that can only be considered defensive programming, not
a first line of defense, as it breaks down in quite a number of
scenarios.
> If not, why not just have Home set it (versus a separate one-time
> Provision app)? Or will that cause problems with alternative home apps?
>
>> Am I missing something obvious?
>
> Other than the above, and assuming your assessment that AOSP does not
> need anything else from SetupWizard holds true, your logic seems sound.
> But, then again, I'm a SetupWizard n00b...
that SetupWizard does is specific to Google apps and therefore isn't
necessary "on its own" in a pure AOSP environment.
> --
> Mark Murphy (a Commons Guy)
> http://commonsware.com | http://twitter.com/commonsguy
>
> Looking for Android opportunities? http://wiki.andmob.org/hado
>
> >
>
Shachar Shemesh
I believe that, other than setting the provisioned bit, everything that SetupWizard does is specific to Google apps and therefore isn't necessary "on its own" in a pure AOSP environment.
First, it gives a brief tutorial on using Android.
The second is it checks whether the carrier supports setting the phone's time. If it does, it sets the "automatically set the time" flag in settings. If it does not (or if the phone has not had a chance to synchronize with the carrier yet, if you move through the wizard really quickly), it brings you to the date/time settings activity.
All the above based on my observations of the HTC Magic doing numerous resets with a couple of SIMs (one of which does not support automatic date/time setting via the carrier).
Shachar
-- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com
Jean-Baptiste Queru
I don't think that those aspects are quite fundamental to the
experience for users who'll be using community builds, but it'd be
good to consider having replacements for them (including maybe getting
Google to open-source that part of SetupWizard).
I've filed http://b.android.com/4028 to track this.
JBQ
Jean-Baptiste Queru
Instead of having a provisioning app enabled by default in all builds,
we'll make it optional in the "core" system, and we'll create a build
configuration specifically for AOSP builds (we can't use "generic" for
that, because it's the base of a deep inheritance hierarchy). Having a
build configuration will allow to specifically control aspects that
are relevant in a pure AOSP build.
I'll try to get on this tomorrow.
JBQ