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 -~----------~----~----~----~------~----~------~--~---
