JBQ,

Thank you for the answers!  They could be good enough to us to dig into the
code and see how we should design it.

Thanks,

Zoneson

On Tue, Dec 2, 2008 at 3:06 PM, Jean-Baptiste Queru <[EMAIL PROTECTED]> wrote:

>
> Even then you can't force an upgrade, you can just force the G1 to
> immediately check whether an update is scheduled for that specific
> device. If your individual device isn't scheduled for an update,
> checking for an update won't change anything about that.
>
> I'd say that parts of the open-source stuff is DownloadProvider, and
> part is recovery (I don't know where recovery actually lives).
>
> JBQ
>
> On Tue, Dec 2, 2008 at 2:58 PM, zoneson chen <[EMAIL PROTECTED]> wrote:
> > JBQ,
> >
> > I thought that we could force the upgrade from G1 directly,  In fact, I
> was
> > wrong.  It looks like that I need AnyCut in order to do it.
> >
> > Would you mind pointing us where is the starting code in open source
> after
> > the proprietary trigger?
> >
> > Thanks,
> >
> > Zoneson
> >
> > On Tue, Dec 2, 2008 at 2:00 PM, Jean-Baptiste Queru <[EMAIL PROTECTED]>
> wrote:
> >>
> >> I'm not quite sure what you mean. The only "manual" upgrade process
> >> I'm aware of goes through an update.zip file on the SD card, loaded
> >> via alt-s in recovery, and that process bypasses just about
> >> everything.
> >>
> >> JBQ
> >>
> >> On Tue, Dec 2, 2008 at 1:56 PM, zoneson chen <[EMAIL PROTECTED]> wrote:
> >> > JBQ,
> >> >
> >> > Thanks!  Does the proprietary mechanism trigger the release checking
> and
> >> > downloading similar to manual upgrade?
> >> >
> >> > Thanks,
> >> >
> >> > Zoneson
> >> >
> >> > On Tue, Dec 2, 2008 at 1:43 PM, Jean-Baptiste Queru <[EMAIL PROTECTED]>
> >> > wrote:
> >> >>
> >> >> The OTA trigger code in the G1 is proprietary to Google and isn't in
> >> >> the open-source code.
> >> >>
> >> >> JBQ
> >> >>
> >> >> On Tue, Dec 2, 2008 at 1:40 PM, zoneson chen <[EMAIL PROTECTED]>
> wrote:
> >> >> > Hi Dianne,
> >> >> >
> >> >> > If we would like to provide the revision service to our customers,
> do
> >> >> > we
> >> >> > have to go through OHA?  If not, would you mind pointing us where
> is
> >> >> > the
> >> >> > code to handle the OTA trigger from T-Mobile in G1 case?
> >> >> >
> >> >> > Thanks,
> >> >> >
> >> >> > Zoneson
> >> >> >
> >> >> > On Tue, Dec 2, 2008 at 12:03 PM, Dianne Hackborn
> >> >> > <[EMAIL PROTECTED]>
> >> >> > wrote:
> >> >> >>
> >> >> >> I'm sure there has, but that's probably not something most if any
> of
> >> >> >> us
> >> >> >> here know about.  If you are working on shipping a device, you
> >> >> >> should
> >> >> >> probably get in contact through the OHA.
> >> >> >>
> >> >> >> On Tue, Dec 2, 2008 at 12:00 PM, Jay Freeman (saurik)
> >> >> >> <[EMAIL PROTECTED]>
> >> >> >> wrote:
> >> >> >>>
> >> >> >>> I am not saying that I want to install Google's existing OTA,
> >> >> >>> T-Mobile
> >> >> >>> signed updates on my device. I am saying that I am wondering how
> >> >> >>> Google is
> >> >> >>> intending to structure relationships to use their OTA
> >> >> >>> infrastructure
> >> >> >>> for
> >> >> >>> other vendors. In essence I "want to work with Google to supply
> >> >> >>> [my]
> >> >> >>> own
> >> >> >>> system images to [my] own phones through their update servers",
> and
> >> >> >>> am
> >> >> >>> wondering if there has been any thought put into that process on
> >> >> >>> their
> >> >> >>> side,
> >> >> >>> past T-Mobile and the G1. -J
> >> >> >>> From: Dianne Hackborn
> >> >> >>> Sent: Tuesday, December 02, 2008 10:10 AM
> >> >> >>> To: [email protected]
> >> >> >>> Subject: [android-porting] Re: enabling OTA updates for my device
> >> >> >>> It probably doesn't even make sense to utilize the Google OTA
> >> >> >>> server
> >> >> >>> --
> >> >> >>> Google is supplying updates currently for the G1, which are a
> >> >> >>> specific
> >> >> >>> build
> >> >> >>> configuration signed with certificates owned by the people who
> make
> >> >> >>> that
> >> >> >>> device (HTC and T-Mobile).  You wouldn't want that OTAed on to a
> >> >> >>> phone
> >> >> >>> with
> >> >> >>> your own build, because the certificates wouldn't match what is
> >> >> >>> installed
> >> >> >>> and all hell would break loose when it boots with the new
> >> >> >>> certificates
> >> >> >>> if
> >> >> >>> you even hacked it to install the update at all.  And even if you
> >> >> >>> got
> >> >> >>> that
> >> >> >>> all to work, what you'd be receiving is the standard G1 build,
> >> >> >>> losing
> >> >> >>> whatever you have customized.
> >> >> >>>
> >> >> >>> I'm not sure what you are wanting to accomplish, but generally
> you
> >> >> >>> would
> >> >> >>> either want to work with Google to supply your own system images
> to
> >> >> >>> your own
> >> >> >>> phones through their update servers, or you can look at the code
> in
> >> >> >>> the
> >> >> >>> device for talking with those servers and implement your own; I
> >> >> >>> don't
> >> >> >>> think
> >> >> >>> it is a super-complicated server protocol, though probably a
> little
> >> >> >>> convoluted to follow.
> >> >> >>>
> >> >> >>> On Tue, Dec 2, 2008 at 5:53 AM, Jean-Baptiste Queru
> >> >> >>> <[EMAIL PROTECTED]>
> >> >> >>> wrote:
> >> >> >>>>
> >> >> >>>> As I understand, the short answer is that right now "it's
> >> >> >>>> Google-specific".
> >> >> >>>>
> >> >> >>>> I have a bit of second-hand knowledge about the update system,
> >> >> >>>> though
> >> >> >>>> (since I do have some first-hand knowledge of code that it works
> >> >> >>>> directly with). That still second-hand knowledge, though, so
> take
> >> >> >>>> it
> >> >> >>>> with a grain of salt:
> >> >> >>>>
> >> >> >>>> -the first step is to determine that there's an update
> available.
> >> >> >>>> That's the Google-specific part, and that's also the part that
> I'm
> >> >> >>>> the
> >> >> >>>> least familiar with. The basic idea about how it's implemented
> >> >> >>>> right
> >> >> >>>> now is that the device sends information about itself to an
> update
> >> >> >>>> server (e.g. IMEI + current version) and the server responds
> >> >> >>>> whether
> >> >> >>>> an update is available for that specific device, along with the
> >> >> >>>> URI
> >> >> >>>> for that update.
> >> >> >>>>
> >> >> >>>> -the second step is to download the actual bits, typically into
> >> >> >>>> /cache. Using the download manager is the recommended option
> here
> >> >> >>>> (because it's been pretty well tested, and because it deals
> >> >> >>>> reasonably
> >> >> >>>> well with managing space on /cache for that specific case),
> though
> >> >> >>>> I
> >> >> >>>> guess that there are other options.
> >> >> >>>>
> >> >> >>>> -the third step is to reboot into recovery mode with the proper
> >> >> >>>> information passed into the recovery code. I don't think that
> this
> >> >> >>>> code is Google-specific, but it's not open-source and it might
> be
> >> >> >>>> version-specific, so if you rebuild it by looking at the
> recovery
> >> >> >>>> code
> >> >> >>>> you could end up with something that doesn't work on future
> >> >> >>>> versions.
> >> >> >>>> I guess it'd be good if that could be covered by system class
> (to
> >> >> >>>> deal
> >> >> >>>> with the compatibility issue), but it's not my decision to make
> >> >> >>>> (and
> >> >> >>>> I
> >> >> >>>> guess it won't happen in the immediate future).
> >> >> >>>>
> >> >> >>>> -you can of course sprinkle just about any UI you want along the
> >> >> >>>> various steps of the process.
> >> >> >>>>
> >> >> >>>> JBQ
> >> >> >>>>
> >> >> >>>> On Tue, Dec 2, 2008 at 1:44 AM, Jay Freeman (saurik)
> >> >> >>>> <[EMAIL PROTECTED]>
> >> >> >>>> wrote:
> >> >> >>>> > So, let's say that I've succeeded in getting Android running
> on
> >> >> >>>> > my
> >> >> >>>> > device.
> >> >> >>>> > Is OTA updates from Google something that only really
> >> >> >>>> > large-scale
> >> >> >>>> > providers
> >> >> >>>> > like T-Mobile are going to be able to do? -J
> >> >> >>>> > >
> >> >> >>>> >
> >> >> >>>>
> >> >> >>>>
> >> >> >>>
> >> >> >>>
> >> >> >>>
> >> >> >>> --
> >> >> >>> Dianne Hackborn
> >> >> >>> Android framework engineer
> >> >> >>> [EMAIL PROTECTED]
> >> >> >>>
> >> >> >>> 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.
> >> >> >>>
> >> >> >>>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> --
> >> >> >> Dianne Hackborn
> >> >> >> Android framework engineer
> >> >> >> [EMAIL PROTECTED]
> >> >> >>
> >> >> >> 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.
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >> > >
> >> >> >
> >> >>
> >> >>
> >> >
> >> >
> >> > >
> >> >
> >>
> >>
> >
> >
> > >
> >
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
unsubscribe: [EMAIL PROTECTED]
website: http://groups.google.com/group/android-porting
-~----------~----~----~----~------~----~------~--~---

Reply via email to