Setting the"provisioned" bit

[Jean-Baptiste Queru]

Right now, some of the base framework features (green key, home key,
and lockscreen) are tied to whether SetupWizard has run successfully.

Unfortunately, SetupWizard is Google-proprietary and is not included
in the open-source git repository. Because of that, builds generated
from the publicly available source tree have those features disabled,
which makes the resulting annoying to use.

Wouldn't it make more sense to set the "provisioned" bit when Home
starts instead of doing it when SetupWizard completes? This is
something that only matters when booting the first time, and at the
point the user can't have installed an alternative Home yet so there's
no risk of running a variant of Home that doesn't have that code.

Thoughts?

JBQ

--
Jean-Baptiste M. "JBQ" Queru
Android Engineer, Google.

[Al Sutton]

An alternative might be forcing the SetupWizard to disable the keys when
it starts and re-enable them when it ends.

That way it can stay as self contained functionality as opposed to
having to make changes to the git repository to accommodate a single app.

Al.

--
======
Funky Android Limited is registered in England & Wales with the
company number 6741909. The registered head office is Kemp House,
152-160 City Road, London, EC1V 2NX, UK.

The views expressed in this email are those of the author and not
necessarily those of Funky Android Limited, it's associates, or it's
subsidiaries.

[Jean-Baptiste Queru]

Well, that'd still require some logic in the core system to say that
the device is provisioned if the property isn't set. On top of that
it'd introduce a race condition during the first boot where there'd be
a period of time where the user would escape from SetupWizard.

JBQ

--

[Al Sutton]

The provisioned flag could become a shared property the wizard checks
and sets.

As for the race condition, I can actually see it's existence as
beneficial because it would help all those users who have already tried
to get around the wizard due to problems with their network setup. The
apps that require the setup wizard to have run could check the shared
wizard property and restart it if it hasn't completed.

That way there is a clean separation between the OS and the proprietary
apps.

Al.

[Jean-Baptiste Queru]

Well, it's actually a requirement in some configurations that
setupwizard can't be bypassed.

JBQ

--

[Disconnect]

If you are going to ad hacks into the main tree for proprietary apps, perhaps it should be a requirement that a reference implementation of that app go in as well..

[Jean-Baptiste Queru]

Well, there's SdkSetup, but it's only built for the SDK, not for device builds.

JBQ

[Jean-Baptiste Queru]

I'm thinking, maybe we could have SdkSetup always built and enabled by
default, and SetupWizard could be run at a higher priority and disable
SdkSetup when it's done running.

This way, if SetupWizard is present, it runs and SdkSetup doesn't.
Otherwise, SdkSetup runs. Either way the device is properly configured
by the time the Home app starts.

(Of course we'd have to rename SdkSetup to something else)

JBQ

[Romain Guy]

Definitely a much better idea than relying on Home for provisioning.

--
Romain Guy
Android framework engineer
roma...@android.com

Note: please don't send private questions to me, as I don't have time
to provide private support. All such questions should be posted on
public forums, where I and others can see and answer them

[Al Sutton]

Couldn't a proprietary bootloader/init script handle that by making the
Wizard the default home screen and the wizard sets the home screen to
what it should be upon completion?

Al

[Jean-Baptiste Queru]

The way it's currently done (by making setup wizard a home screen at
build time, with a higher priority than the real home, and having
setup wizard disable itself after it runs) seems to be achieve the
same result without relying on a boot-time system that'd need to run
late enough to be able to determine whether this is the first run or
not and to set the appropriate settings but early enough to avoid the
race condition.

JBQ

--

[Al Sutton]

Or possibly the wizard could start on every boot but if it finds valid
configuration settings it immediately exits unless a flag is passed to
it to which could force it to run (the flag would be used if the wizard
is started at a user request or if a program detects a problem with the
wizard generated configuration).

Al.

[Jean-Baptiste Queru]

Well, if setupwizard exits the system will restart it immediately
(since it's the home screen).

JBQ

--

[Joe Onorato]

It seems to me that "requires provisioning" shouldn't be the default, and that there should be a system property that the system checks before allowing an unprovisioned system to work.

In pseudocode:
if (ro.requires_provisioning && !system.provisioned) {
  fail();
}

By default ro.requires_provisioning would be false, and on builds where it is required, the build system can be asked to set it to true.  There is already support to set system properties on a product basis.

-joe

[Al Sutton]

OK, so the setup wizard sets the normal home screen and then exits :).

Al.

I'm assuming that under the covers there is still he

[Jean-Baptiste Queru]

That becomes messy if the user installs another home screen.

JBQ

--

[Al Sutton]

I've not delved the depths of home screens, but surely it's a Highlander
thing and there can be only one and so could be a configuration setting?

What would be the benefit of running multiple home screens if the user
can only interact with one?

Al.

[Jean-Baptiste Queru]

There can be multiple home screens installed, and the user will be
prompted to choose which one they want to use. All home screens are
equal, really.

JBQ

--

[Al Sutton]

But once they've made the selection the choice is stored and thus the
setup wizard can find out who to hand over to?

Al.

[Jean-Baptiste Queru]

The result is only stored if the user says that they want to use that
app for that action in the future (and if they don't clear the
setting, or delete the app, etc...). It's much easier to have setup
wizard disable itself and finish() itself the way I assume it
currently does (SdkSetup does it that way, and it looks elegant).

JBQ

--

[Al Sutton]

As long as it doesn't need a hack in the git to support then it looks
like the best solution.

[Jean-Baptiste Queru]

Sounds good. I like the notion that the core system itself would rely
on something lower (read-only system properties) instead of something
higher (an actual applications). I'll look into that to evaluate the
implementation complexity.

JBQ

[Jean-Baptiste Queru]

First cut is up for review:
http://review.source.android.com/7706
http://review.source.android.com/7707
http://review.source.android.com/7708

Thanks,
JBQ

[Jean-Baptiste Queru]

The first set of changes was submitted. However, Dave made a very good
suggestion in the review comments of 7708:

"Apps shouldn't be using SystemProperties directly; it's a hidden API
that we're trying to weed out from all apps. The framework should
read the property and publish it via a static final or a method."

I have no problem implementing that change, but I'd like some guidance
on the best location to put that new API in.

Thanks,
JBQ

[Al Sutton]

Any reason you've used Settings.Secure instead of Settings.System?

At the moment getting the ID of the 'phone can be done using;

Settings.System.getString(getContentResolver(), Settings.System.ANDROID_ID);

(and is used by a number of people using licensing), Wouldn't it be logical to do something like;

Settings.System.getString(getContentResolver(), Settings.System.NEEDS_PROVISIONING);

?

Al.

P.S. The reason I'm questioning this is more about my lack of knowledge on cupcake than anything else.

[Al Sutton]

Maybe getString isn't the best methods, but I hope you get the idea....

Al.

[Jean-Baptiste Queru]

Is the question, rather, why I used SystemProperties instead of
Settings? In a nutshell, SystemProperties are backed by stuff that is
configured through the build system.

I'm going to look at introducing a new public (SDK) API for such
situations, instead of spreading the usage of a private APIs into
application that have no business using them. Watch this space.

JBQ

[Dianne Hackborn]

Fwiw, ANDROID_ID is now officially in Settings.Secure, and Settings.System.ANDROID_ID remains only for backwards compatibility.  We are introducing Settings.Secure for settings that applications are not allowed to directly modify, regardless of the permissions they have.

On Fri, Jan 16, 2009 at 2:14 PM, Al Sutton <a...@funkyandroid.com> wrote:

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support.  All such questions should be posted on public forums, where I and others can see and answer them.

[Al Sutton]

@JBQ It was just showing my lack of knowlege of cupcake and what had
moved to Settings.Secure

@Dianne Thanks for the clarification. Is there a way for apps to
determine which they should look for in case devices in the pipeline are
rolled out with Android 1.0 and don't have Settings.Secure?

Al.

> <mailto:a...@funkyandroid.com>> wrote:
>
>
>
> Couldn't a proprietary
> bootloader/init script handle that
> by making
> the
> Wizard the default home screen and
> the wizard sets the home screen to
> what
> it should be upon completion?
>
> Al
>
> Jean-Baptiste Queru wrote:
>
>
>
> Well, it's actually a
> requirement in some
> configurations that
> setupwizard can't be bypassed.
>
> JBQ
>
> On Wed, Jan 14, 2009 at 7:46
> AM, Al Sutton
> <a...@funkyandroid.com

> <mailto:a...@funkyandroid.com>>

> <mailto:a...@funkyandroid.com>>

> hac...@android.com <mailto:hac...@android.com>

[Dianne Hackborn]

On Fri, Jan 16, 2009 at 2:31 PM, Al Sutton <a...@funkyandroid.com> wrote:

@Dianne Thanks for the clarification. Is there a way for apps to determine which they should look for in case devices in the pipeline are rolled out with Android 1.0 and don't have Settings.Secure?

You can continue to retrieve from the original place, we need to do that for compatibility.  We will be putting some new settings in secure, and some existing ones can now only be changed in secure.

--
Dianne Hackborn
Android framework engineer
hac...@android.com