The new update 2.2.20.A955 does not fix the issue, even with a hard reset.... the ANDROID_ID on my droid 2 is still 9774d56d682e549c.
On Aug 23, 10:20 am, Ben Pellow <benjamin.pel...@gmail.com> wrote: > Assuming new devices are fixed moving forward, I'm curious about > devices remaining in market with this problem. Will an OTA update to > Gingerbread fix theANDROID_IDfor clients with the default one? I'm > guessingANDROID_IDpersists across os updates and that only hard > reset will spawn a new one, after a device has updated to a version of > the os/firmware that will correctly set it? My assumption, correct me > if I'm wrong: In order to cure this insecure android id, a client > must both update and reset? > > -Ben > > On Aug 21, 6:28 am, OldSkoolMark <m...@sublimeslime.com> wrote: > > > > > Perhaps this has already been answered in the originating thread, but > > I couldn't find it. The LVL docs suggest using additional features > > besidesANDROID_ID, and the question was which? Dianne Hackborne had > > issues with using the IMEI. Is using the MAC address a better option? > > > On Aug 20, 12:04 pm, Trevor Johns <trevorjo...@google.com> wrote: > > > > Hi everyone, > > > Just to follow up a bit here, the reason we believe this is happening is > > > because ro.serialno isn't set on these devices. (Note that the ro.* > > > properties currently aren't required by the CDD/CTS.) Unfortunately, it > > > seems that we're using ro.serialno as the seed for the PRNG when > > > generating > > >ANDROID_ID. > > > > See: > > > frameworks/base/packages/SettingsProvider/src/com/android/providers/setting > > > s/SettingsProvider.java:416 > > > >http://www.google.com/codesearch/p?hl=en#uX1GffpyOZk/packages/Setting... > > > > I've gone ahead and opened up a bug here for tracking purposes: > > > >http://code.google.com/p/android/issues/detail?id=10639 > > > > (We suspect that the Droid 2 isn't the only phone affected by this, likely > > > just the most noticeable instance.) > > > > We have a fix for this checked into our internal Git repo, so once that > > > change propagates to vendors this shouldn't be an issue on future devices. > > > For existing devices though, if you absolutely depend on the uniqueness of > > >ANDROID_ID, you'll unfortunately need to rely on some other identifier > > > (IMEI, WiFi MAC, etc.). > > > > -- > > > Trevor Johns > > > > On Fri, Aug 20, 2010 at 10:46 AM, suzanne.alexandra < > > > > suzanne.alexan...@motorola.com> wrote: > > > > Andrew, > > > > I don't know that this is reported in any public bug system. I've > > > > reported it within a Motorola bug system. > > > > > - Suzanne > > > > > On Aug 20, 12:33 am, "Maps.Huge.Info (Maps API Guru)" > > > > <cor...@gmail.com> wrote: > > > > > > John, have you had any complaints yet about conflicts from duplicate > > > > > > unique ids? > > > > > > I handled it in code. > > > > > > -John Coryat > > > > > -- > > > > You received this message because you are subscribed to the Google > > > > Groups "Android Developers" group. > > > > To post to this group, send email to android-developers@googlegroups.com > > > > To unsubscribe from this group, send email to > > > > android-developers+unsubscr...@googlegroups.com<android-developers%2Bunsubs > > > > cr...@googlegroups.com> > > > > For more options, visit this group at > > > >http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
