I'm seeing hundreds (877 at last count) of Froyo equipped devices
using our app with the same ANDROID_ID this month. Normally, this ID
is a unique thing but now it isn't.
I'm guessing this is due to a custom ROM with some invalid settings as
the device is a DROID2 and as far as I know, the DROID2 hasn't been
released yet.
On Sun, Aug 15, 2010 at 2:10 PM, Maps.Huge.Info (Maps API Guru)
<cor...@gmail.com> wrote: > It appears the Droid2 has got a mistake in the OS. All Droid2 devices > have the same ANDROID_ID: 9774d56d682e549c
> How in the heck could Motorola and Verizon make such a fatal error?
I don't think Verizon has much to do with it. Also, bear in mind that CTS-type tests are unlikely to uncover this sort of problem, since they only test one device at a time, AFAIK.
Just to clarify, by "this problem" you mean having the same ANDROID_ID as others of its model, or having this one magic ANDROID_ID?
If the latter...do you distribute your app outside of the Android Market?
> Looks like this problem is wider than just Motorola, although it could > be the other devices are custom ROM's.
Custom ROMs would be one possibility -- the ROM mixer might have grabbed the ANDROID_ID value out of the emulator.
The reason I asked about distribution is that I seem to recall that ANDROID_ID is somehow tied into Google accounts and the Android Market. I'm wondering if this magic ANDROID_ID is the new default value. If so, devices that are not set up with the Android Market (e.g., emulator) might return this value. That wouldn't explain the DROID2 -- if 100% of DROID2's aren't getting the Market, that'd be *huge* -- but it might explain some of your other ones.
> So prior to this month, there were no duplicate ANDROID_IDs? With pre-
> Froyo devices?
I can't say there were or weren't any duplicates pre-Froyo. I can say
that every Droid2 that has downloaded my app "Radar Now!" has the same
ANDROID_ID.
On 16 Aug., 06:43, "Maps.Huge.Info (Maps API Guru)" <cor...@gmail.com>
wrote:
> > So prior to this month, there were no duplicate ANDROID_IDs? With pre-
> > Froyo devices?
> I can't say there were or weren't any duplicates pre-Froyo. I can say
> that every Droid2 that has downloaded my app "Radar Now!" has the same
> ANDROID_ID.
> -John Coryat
If you look into the SettingsProvider class, then you can see that
this is done using
SecureRandom random = SecureRandom.getInstance("SHA1PRNG");
When the persistent system property ro.serialno is set, then this
value
will be used to reseeds this random object.
Later comes a random.nextLong transformed to a Hex-String.
Interessting might be this part of the javadoc:
"the system will determine if there is an implementation of the
algorithm requested available in the environment"
Maybe their is a problem with this SHA1PRNG algorithm ?
On Aug 16, 8:06 pm, "Maps.Huge.Info (Maps API Guru)"
<cor...@gmail.com> wrote:
> Seems to be a problem that's mostly with the DROID2.
Yeah, I strongly suspect those others are indeed custom builds,
looking at the devices. What's an MSM?
On Aug 15, 8:34 pm, Kostya Vasilyev <kmans...@gmail.com> wrote:
> So what should be used for the new licensing service on this device?
That's the thing I'm most concerned about as well, at this point. I'd
REALLY like to hear from Mountain View on that topic. Trevor, you
still out there?
Hi everyone,
I've been trying to investigate this on my end, but unfortunately I
seem to having some trouble finding a Droid 2 in the office to
actually reproduce this with.
If anybody has access to a device that's exhibiting this behavior,
would you please send me a copy of the build fingerprint?
(Settings > About phone > Build number)
Thanks!
--
Trevor Johns
On Aug 16, 12:45 pm, String <sterling.ud...@googlemail.com> wrote:
> On Aug 16, 8:06 pm, "Maps.Huge.Info (Maps API Guru)"
> <cor...@gmail.com> wrote:
> > Seems to be a problem that's mostly with the DROID2.
> Yeah, I strongly suspect those others are indeed custom builds,
> looking at the devices. What's an MSM?
> On Aug 15, 8:34 pm, Kostya Vasilyev <kmans...@gmail.com> wrote:
> > So what should be used for the new licensing service on this device?
> That's the thing I'm most concerned about as well, at this point. I'd
> REALLY like to hear from Mountain View on that topic. Trevor, you
> still out there?
<cor...@gmail.com> wrote:
> As far as I can tell, every DROID2 has the same ANDROID_ID. It's not
> just a couple, it's ALL. I don't think it's cloning.
> Hi everyone,
> I've been trying to investigate this on my end, but unfortunately I
> seem to having some trouble finding a Droid 2 in the office to
> actually reproduce this with.
> If anybody has access to a device that's exhibiting this behavior,
> would you please send me a copy of the build fingerprint?
> (Settings > About phone > Build number)
> Thanks!
> --
> Trevor Johns
> On Aug 16, 12:45 pm, String <sterling.ud...@googlemail.com> wrote:
> > On Aug 16, 8:06 pm, "Maps.Huge.Info (Maps API Guru)"
> > <cor...@gmail.com> wrote:
> > > Seems to be a problem that's mostly with the DROID2.
> > Yeah, I strongly suspect those others are indeed custom builds,
> > looking at the devices. What's an MSM?
> > On Aug 15, 8:34 pm, Kostya Vasilyev <kmans...@gmail.com> wrote:
> > > So what should be used for the new licensing service on this device?
> > That's the thing I'm most concerned about as well, at this point. I'd
> > REALLY like to hear from Mountain View on that topic. Trevor, you
> > still out there?
<cor...@gmail.com> wrote:
> > Do you think this should be logged at code.google.com as an issue. I
> > did as search for ANDROID_ID there and nothing came up.
> I think the right people are looking into this problem. Hopefully, it
> will turn out to be easy to correct.
The docs say that getDeviceId is the IMEI for GSM or its equivalent for CDMA devices.
Glad it works for you, but I have two issues with this:
1 - It requires a special permission, for no good reason from users' point of view (unless the app already needs this).
2 - There might be devices that don't return the IMEI correctly, just like the DROID 2 doesn't generate the ANDROID_ID correctly.
Note that using the right IMEI value in the low-level cellular radio code (so phone calls work) and returning it all the way to application layer are two different things, at least it would seem that way.
> On Aug 18, 7:41 am, "Maps.Huge.Info (Maps API Guru)" > <cor...@gmail.com> wrote: >>> Do you think this should be logged at code.google.com as an issue. I >>> did as search for ANDROID_ID there and nothing came up. >> I think the right people are looking into this problem. Hopefully, it >> will turn out to be easy to correct.
<cor...@gmail.com> wrote:
> > Do you think this should be logged at code.google.com as an issue. I
> > did as search for ANDROID_ID there and nothing came up.
> I think the right people are looking into this problem. Hopefully, it
> will turn out to be easy to correct.
IMEI is assigned to every phone before it leaves the factory, and doesn't change during its lifetime. It's often printed on the box.
ANDROID_ID is generated by Android, and can change (e.g. when settings are reset).
If it works for you, it's great, but I would like to see a solution that's not tied to the telephony stack. There are devices without a phone radio at all.
> On Aug 18, 7:41 am, "Maps.Huge.Info (Maps API Guru)" > <cor...@gmail.com> wrote: >>> Do you think this should be logged at code.google.com as an issue. I >>> did as search for ANDROID_ID there and nothing came up. >> I think the right people are looking into this problem. Hopefully, it >> will turn out to be easy to correct.
> On Aug 18, 10:25 pm, Kostya Vasilyev<kmans...@gmail.com> wrote: >> IMEI is assigned to every phone before it leaves the factory, and >> doesn't change during its lifetime. It's often printed on the box. > Offtopic: We have thousands of "non-brand" phones with EXACT SAME IMEI > in our market --- all are imported from a single country. > The phones are cheap :)
