Settings.Secure.ANDROID_ID not unique on DROID2?

[Maps.Huge.Info (Maps API Guru)]

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.

Here's the user agent string:

Dalvik/1.2.0 (Linux; U; Android 2.2; DROID2 Build/VZW)

Has anyone else run into this problem yet?

-John Coryat

[Maps.Huge.Info (Maps API Guru)]

Update:

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?

-John Coryat

[Seni Sangrujee]

> have the same ANDROID_ID: 9774d56d682e549c

That's not good. This is not going to be fun to work around.

That looks like the same ANDROID_ID as here:
http://groups.google.com/group/android-developers/browse_thread/thread/f1b229e951114509/bcabfa6b83e153d1#bcabfa6b83e153d1

-seni

[Kostya Vasilyev]

So what should be used for the new licensing service on this device? Any ideas?

--
Kostya Vasilyev -- http://kmansoft.wordpress.com

15.08.2010 23:20 пользователь "Seni Sangrujee" <sang...@gmail.com> написал:

--
You received this message because you are subscribed to the Google
Groups "Android Developers" ...

[Mark Murphy]

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.

--
Mark Murphy (a Commons Guy)
http://commonsware.com | http://github.com/commonsguy
http://commonsware.com/blog | http://twitter.com/commonsguy

_The Busy Coder's Guide to Android Development_ Version 3.1 Available!

[Maps.Huge.Info (Maps API Guru)]

More on this bizarre error:

Here are other devices I see (for the month of August only) that have
this probem:

753 DROID2
4 DROIDX
1 European Vogue
2 Full Android on Vogue
90 HTC Desire
15 HTC HD2
1 HTC Vogue FroYo
1 LG-MS690
2 MSM
4 Nexus One
1 boydTouch HD2
2 thunderc

Here are the builds:

117 FRF91
2 MASTER
757 VZW

Looks like this problem is wider than just Motorola, although it could
be the other devices are custom ROM's.

-John Coryat

[Mark Murphy]

On Sun, Aug 15, 2010 at 4:47 PM, Maps.Huge.Info (Maps API Guru)
<cor...@gmail.com> wrote:
> Here are other devices I see (for the month of August only) that have
> this probem:
>
> 753     DROID2
> 4       DROIDX
> 1       European Vogue
> 2       Full Android on Vogue
> 90      HTC Desire
> 15      HTC HD2
> 1       HTC Vogue FroYo
> 1       LG-MS690
> 2       MSM
> 4       Nexus One
> 1       boydTouch HD2
> 2       thunderc
>
> Here are the builds:
>
> 117     FRF91
> 2       MASTER
> 757     VZW

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.

[Maps.Huge.Info (Maps API Guru)]

My apps are distributed strictly through the Android market. All the
devices I listed have the same exact ANDROID_ID.

-John Coryat

[OldSkoolMark]

So prior to this month, there were no duplicate ANDROID_IDs? With pre-
Froyo devices?

On Aug 15, 1:47 pm, "Maps.Huge.Info (Maps API Guru)"

[Maps.Huge.Info (Maps API Guru)]

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

[FrankG]

On 16 Aug., 06:43, "Maps.Huge.Info (Maps API Guru)" <cor...@gmail.com>
wrote:

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 ?

Try to set "ro.serialno" with setprop ..

Good luck !

Frank

[Maps.Huge.Info (Maps API Guru)]

Update:

Here are the numbers I've seen for July (ANDROID_ID =
9774d56d682e549c):

24 DROID2
4 DROIDX
3 European Vogue
11 HTC Desire
1 HTC HD2
4 HTC Vogue FroYo
40 MSM
10 Nexus One

Builds:

29 FRF91
44 MASTER
24 VZW

Seems to be a problem that's mostly with the DROID2.

-John Coryat

[String]

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?

String

[Trevor Johns]

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

[DanH]

Could this behavior be explained by someone cloning phones?

On Aug 16, 2:06 pm, "Maps.Huge.Info (Maps API Guru)"

[Maps.Huge.Info (Maps API Guru)]

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.

-John Coryat

[OldSkoolMark]

John,

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.

On Aug 17, 6:55 pm, "Maps.Huge.Info (Maps API Guru)"

[String]

Hi Trevor,

It's good to hear from you on this issue.

I have to say, though, that if there's one company that I would have
expected to have an example of every device for testing, it's
Google...

String

[Maps.Huge.Info (Maps API Guru)]

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

-John Coryat

[Nathan]

Great. I can just wait to see if angry customers ask why their trial
is already over.

Nonetheless, I couldn't find 9774d56d682e549c among my trial users.
Maybe no Droid 2s have tried it yet.

I'm using this as the id but I believe it does the same as ANDROID_ID.


TelephonyManager manager =
(TelephonyManager)context.getSystemService(Context.TELEPHONY_SERVICE);

String imei = manager.getDeviceId();

Nathan


On Aug 18, 7:41 am, "Maps.Huge.Info (Maps API Guru)"

[Kostya Vasilyev]

Nathan,

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.

-- Kostya

18.08.2010 19:39, Nathan пишет:

--
Kostya Vasilev -- WiFi Manager + pretty widget -- http://kmansoft.wordpress.com

[Nathan]

I haven't seen that number yet. I'm still waiting for angry users
wondering why their trial expired already.

This is the code I use, but I think it returns the same as ANDROID_ID

TelephonyManager manager =
(TelephonyManager)context.getSystemService(Context.TELEPHONY_SERVICE);

String imei = manager.getDeviceId();

Nathan

On Aug 18, 7:41 am, "Maps.Huge.Info (Maps API Guru)"

[Kostya Vasilyev]

No, this is different.

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.

-- Kostya

18.08.2010 19:49, Nathan пишет:

[Kostya Vasilyev]

How do they connect to the cellular network if they all have the same
IMEI?

Or do they?

-- Kostya

18.08.2010 21:02, Sarwar Erfan пишет:

>
> 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 :)
>
> Regards
> Sarwar Erfan
>
>
>
>>
>> -- Kostya

[Seni Sangrujee]

If this helps, here's what I'm seeing with my apps with the magic
ANDROID_ID=9774d56d682e549c


App #1 tracking urlConnection.getRequestProperty("User-Agent")
7-14 [***.mycingular.net] Dalvik/1.2.0 (Linux; U; Android 2.2; MSM
Build/MASTER)
8-14 (***.myvzw.com] Dalvik/1.2.0 (Linux; U; Android 2.2; DROID2 Build/
VZW)
8-15 [***.myvzw.com] Dalvik/1.2.0 (Linux; U; Android 2.2; DROID2 Build/
VZW)
8-15 [***.myvzw.com] Dalvik/1.2.0 (Linux; U; Android 2.2; DROID2 Build/
VZW)
8-16 [***.myvzw.com] Dalvik/1.2.0 (Linux; U; Android 2.2; DROID2 Build/
VZW)
8-16 [***.myvzw.com] Dalvik/1.2.0 (Linux; U; Android 2.2; DROID2 Build/
VZW)
8-17 [***.myvzw.com] Dalvik/1.2.0 (Linux; U; Android 2.2; DROID2 Build/
VZW)

App #2 tracking android.os.Build.BRAND/PRODUCT/DEVICE/MODEL
8-4 [***.tmodns.net] hkcsl_cht/htc_bravo/bravo/HTC Desire
8-11 [???] Dalvik/1.2.0 (Linux; U; Android 2.2; thunderc Build/MASTER)
8-14 [***.clearwire-wmx.net] htc_wwe/htc_bravo/bravo/HTC Desire

App #3 tracking android.os.Build.BRAND/PRODUCT/DEVICE/MODEL
8-13 [***.myvzw.com] verizon/droid2_vzw/cdma_droid2/DROID2
8-14 [***.myvzw.com] verizon/droid2_vzw/cdma_droid2/DROID2
8-16 [***.myvzw.com] verizon/droid2_vzw/cdma_droid2/DROID2
8-16 [***.myvzw.com] verizon/droid2_vzw/cdma_droid2/DROID2


-seni

[Nathan]

On Aug 18, 9:25 am, Kostya Vasilyev <kmans...@gmail.com> wrote:
>   No, this is different.
>
> 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.
>
> -- Kostya

I don't have enough data to know if I have this solved. I'm worried
about devices that don't have a phone radio too.

But I would also be worried about and ANDROID_ID if it changes often,
or, in the case of Droid 2, not changing enough.

Nathan

[DanH]

But at least the IMEI is more likely to be unique, since telephone
connections depend on it, and checking its uniqueness (and
correspondence to the printed label) is probably written into some
stringent phone qualification tests.

[Maps.Huge.Info (Maps API Guru)]

I'm relieved to see that I'm not the only one who's seeing the "magic"
ANDROID_ID problem.

-John Coryat

[Sarwar Erfan]

On Aug 18, 11:18 pm, Kostya Vasilyev <kmans...@gmail.com> wrote:
>   How do they connect to the cellular network if they all have the same
> IMEI?
>
> Or do they?
>

They do connect to the network, no restriction from the operators. The
problems we are facing that --- criminals are using those sets and as
their IMEI are not unique, law enforcement authorities are not being
able to track them.

Our country is not the only sufferer.
http://bit.ly/aeLyQx

Some even DO NOT have IMEI at all!
http://bit.ly/dCHM6s

(May be we should not discuss more on off-topic on this thread)

[Seni Sangrujee]

On Aug 18, 10:48 am, "Maps.Huge.Info (Maps API Guru)"

<cor...@gmail.com> wrote:
> I'm relieved to see that I'm not the only one who's seeing the "magic"
> ANDROID_ID problem.

Yeah, I'm surprised there haven't been more reports from apps that
depend on ANDROID_ID.

It looks like it's a known issue with custom ROMs from these two
links:

Android ID same as Android emulator
http://forum.xda-developers.com/showpost.php?p=7251507&postcount=1110

Allways the same Android_ID
http://forum.xda-developers.com/showthread.php?p=7702995

[Indicator Veritatis]

I am amazed the local telecom regulators let them get away with such a
blatant violation of the spec, one that pollutes the market and
network! So amazed, I have to doubt: is it really the IMEI that is the
same on each unit? What do they think is going to happen when a
customer loses a phone and asks the carrier to disable it? They do
this by IMEI, not phone number.

On Aug 18, 10:02 am, Sarwar Erfan <erfanonl...@gmail.com> wrote:
> 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.
>

[Kostya Vasilyev]

It's my understanding this company doesn't make Android based phones, and if they did, they won't be submitting them to Google for Android certification. So no Market and no LVL for these.

It *is* pretty amazing, though.

--
Kostya Vasilyev -- http://kmansoft.wordpress.com

19.08.2010 0:58 пользователь "Indicator Veritatis" <mej...@yahoo.com> написал:

I am amazed the local telecom regulators let them get away with such a
blatant violation of the spec, one that pollutes the market and
network! So amazed, I have to doubt: is it really the IMEI that is the
same on each unit? What do they think is going to happen when a
customer loses a phone and asks the carrier to disable it? They do
this by IMEI, not phone number.

On Aug 18, 10:02 am, Sarwar Erfan <erfanonl...@gmail.com> wrote:

> On Aug 18, 10:25 pm, Kostya Vasi...

[Sarwar Erfan]

On Aug 19, 2:54 am, Indicator Veritatis <mej1...@yahoo.com> wrote:
> same on each unit? What do they think is going to happen when a
> customer loses a phone and asks the carrier to disable it? They do
> this by IMEI, not phone number.

Its simple, they don't provide the service to disable phones :)

Regards
Sarwar Erfan

[suzanne.alexandra]

I'm looking into this from Motorola - thanks to Mark for calling it to
my attention. (You can also post questions on Motorola devices at
developer.motorola.com.)

To confirm, the DROID 2 is not yet released.

- Suzanne

[Kostya Vasilyev]

So there is hope that this issue can be fixed before the release, correct?

--
Kostya Vasilyev -- http://kmansoft.wordpress.com

20.08.2010 0:54 пользователь "suzanne.alexandra" <suzanne....@motorola.com> написал:

I'm looking into this from Motorola - thanks to Mark for calling it to
my attention. (You can also post questions on Motorola devices at
developer.motorola.com.)

To confirm, the DROID 2 is not yet released.

- Suzanne

On Aug 18, 10:18 am, Kostya Vasilyev <kmans...@gmail.com> wrote:

>   How do they connect to the...

--
You received this message because you are subscribed to the Google
Groups "Android Developers" g...

[String]

On Aug 19, 9:54 pm, "suzanne.alexandra"

<suzanne.alexan...@motorola.com> wrote:

> To confirm, the DROID 2 is not yet released.

Excuse me? By all accounts, the Droid 2 was released last week.

"the Droid 2 is now up for sale on Verizon" (Aug 11)
http://www.engadget.com/2010/08/11/verizon-droid-2-sales-begin/

"the Droid 2, which recently launched on Verizon's network"
http://arstechnica.com/gadgets/reviews/2010/08/hands-on-motorolas-droid-sequel-is-a-worthy-update.ars

And here it is, available now at VZW:
http://www.verizonwireless.com/b2c/store/controller?item=phoneFirst&action=viewPhoneDetail&selectedPhoneId=5429&capId=142&phoneTopRated=

String

[Maps.Huge.Info (Maps API Guru)]

Perhaps Suzanne was thinking about another country... it certainly is
out in the USA.

-John Coryat

[suzanne.alexandra]

Got it, thanks, my mistake. My DROID 2 here is returning the same
ANDROID_ID. Checking into it.

- Suzanne



On Aug 19, 2:44 pm, "Maps.Huge.Info (Maps API Guru)"

[Maps.Huge.Info (Maps API Guru)]

Suzanne,

All I can say is "Great" and "Bummer".

Currently, I'm showing 1,168 DROID2's with that ANDROID_ID using my
app.

-John Coryat

[suzanne.alexandra]

John, thanks for the number. I just filed a high-priority bug on this
and will keep you updated.

- Suzanne


On Aug 19, 3:40 pm, "Maps.Huge.Info (Maps API Guru)"

[Andrew]

Suzanne,
Is this reported in any public bug tracking system?

On Aug 19, 6:35 pm, "suzanne.alexandra"

[Seni Sangrujee]

> Currently, I'm showing 1,168 DROID2's with that ANDROID_ID using my
> app.

John, have you had any complaints yet about conflicts from duplicate
unique ids?

-seni

[Maps.Huge.Info (Maps API Guru)]

>
> John, have you had any complaints yet about conflicts from duplicate
> unique ids?
>

I handled it in code.

-John Coryat

[suzanne.alexandra]

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)"

[Trevor Johns]

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/settings/SettingsProvider.java:416

http://www.google.com/codesearch/p?hl=en#uX1GffpyOZk/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java&q=android_id%20ro.serialno&sa=N&cd=1&ct=rc

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

--
You received this message because you are subscribed to the Google

Groups "Android Developers" group.
To post to this group, send email to android-d...@googlegroups.com
To unsubscribe from this group, send email to
android-develop...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[Maps.Huge.Info (Maps API Guru)]

How is the market licensing system affected by this?

-John Coryat

[Trevor Johns]

Right now, we use the ANDROID_ID to prevent copying the license cache between devices when using ServerManagedPolicy. In this case, you'll be able to copy this cache between any two devices that have the same ANDROID_ID.

However, you still won't be able to modify the license cache, and you won't be able to renew the license. So, after the license expires (~7 days), the application will try and contact Android Market again and the license check will fail.

StrictPolicy is unaffected.

-- 

Trevor Johns

On Fri, Aug 20, 2010 at 12:19 PM, Maps.Huge.Info (Maps API Guru) <cor...@gmail.com> wrote:

How is the market licensing system affected by this?

-John Coryat

[Wayne Wenthin]

Having to retrofit this into my code will be a nightmare for me.   I don't force upgrades and I rely on this in several places in my backend database.     I will be sending out a message and marking my app as not compatible with the droid 2.   Sigh.

--
Follow us on Twitter  @fuliginsoftware
Join the forums.
http://www.fuligin.com/forums

[FrankG]

Hi Trevor,

This was my impression too on the 16th August

"Try to set "ro.serialno" with setprop .. "

But I assume that other vendors have also no clue about this property.

Good luck !

Frank

On 20 Aug., 21:04, 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...

> > android-develop...@googlegroups.com<android-developers%2Bunsubs­cr...@googlegroups.com>

> > For more options, visit this group at

> >http://groups.google.com/group/android-developers?hl=en- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -

[Kostya Vasilyev]

Suzanne from Motorola - did you see the info from Trevor, below?

Trevor - perhaps testing for properly set ro.* should be added to CDD / CTS?

-- Kostya

20.08.2010 23:57, FrankG пишет:

[suzanne.alexandra]

An update from my side as well. We've been working with Trevor and
Google, and our kernel engineering team is aware of what needs to
change.

- Suzanne

> > >http://groups.google.com/group/android-developers?hl=en-Zitierten Text ausblenden -

[Kostya Vasilyev]

Great to hear this. Thanks.

--
Kostya Vasilyev -- http://kmansoft.wordpress.com

21.08.2010 2:03 пользователь "suzanne.alexandra" <suzanne....@motorola.com> написал:

An update from my side as well. We've been working with Trevor and
Google, and our kernel engineering team is aware of what needs to
change.

- Suzanne

On Aug 20, 12:57 pm, FrankG <frankgru...@googlemail.com> wrote:
> Hi Trevor,
>

> This was my impre...

[Bob Kerns]

May I suggest doing an SHA-1 hash of the IMEI (if present) and the
ANDROID_ID?

Or if you don't need a fixed length, you can use the concatenation, or
you can fill in an IMEI of 0.

Finally, if you really want to get paranoid, you can check for the bad
ANDROID_ID, and if you have that, and no IMEI, then generate a random
number, seeded from the time and any other source of entropy you can
get your hands on, and persist it.

This is a screwup of the sort of epic proportions that gives engineers
like me nightmares. I've dodged a few bullets like this, generally
affecting fewer customers but having a bigger potential impact on the
company.

Yikes! Good luck in coping...

On Aug 18, 10:33 am, Nathan <critter...@crittermap.com> wrote:
> On Aug 18, 9:25 am, Kostya Vasilyev <kmans...@gmail.com> wrote:
>
> >   No, this is different.

>
> > 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.
>
> > -- Kostya
>
> I don't have enough data to know if I have this solved. I'm worried
> about devices that don't have a phone radio too.
>
> But I would also be worried about and ANDROID_ID if it changes often,
> or, in the case of Droid 2, not changing enough.
>
> Nathan

[OldSkoolMark]

Perhaps this has already been answered in the originating thread, but
I couldn't find it. The LVL docs suggest using additional features
besides ANDROID_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/settings/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-d...@googlegroups.com
> > To unsubscribe from this group, send email to

> > android-develop...@googlegroups.com<android-developers%2Bunsu...@googlegroups.com>

[Ben Pellow]

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 the ANDROID_ID for clients with the default one? I'm
guessing ANDROID_ID persists 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
> besides ANDROID_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

> > > android-develop...@googlegroups.com<android-developers%2Bunsubs cr...@googlegroups.com>

[RealityMaster]

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

[Opted Out]

I'm just coming into the market and can see some use for my
application if each and everyone has a unique ID.

Is there still issues or does it appear to be fixed?

On Aug 18, 1:48 pm, "Maps.Huge.Info (Maps API Guru)"
<cor...@gmail.com> wrote:
> I'm relieved to see that I'm not the only one who's seeing the "magic"ANDROID_IDproblem.
>
> -John Coryat

[gcstang]

What is the issue with using IMEI?

[Maps.Huge.Info (Maps API Guru)]

Using IMEI requires an additional permission. Using ANDROID_ID
doesn't.

-John Coryat

[William Ferguson]

It also assumes the device is a phone.
It may be a wifi only tablet, or whatever.

On Sep 9, 2:09 am, "Maps.Huge.Info (Maps API Guru)" <cor...@gmail.com>
wrote:

[gcstang]

Permission isn't as big an issue but the non phone part is definitely
a concern.

Thank you for you answers

On Sep 8, 10:56 pm, William Ferguson <william.ferguson...@gmail.com>
wrote:

[suzanne.alexandra]

Motorola is working on a fix for the ANDROID_ID issue on DROID 2. Any
fix that becomes available will be upgraded to devices over the air. I
don't have a timeline though.

- Suzanne