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.
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.
JBQ
--
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.
JBQ
--
JBQ
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
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
JBQ
--
Al.
JBQ
--
Al.
I'm assuming that under the covers there is still he
JBQ
--
What would be the benefit of running multiple home screens if the user
can only interact with one?
Al.
JBQ
--
Al.
JBQ
--
JBQ
Thanks,
JBQ
"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
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.
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 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 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?