01.04.2011 9:04, Dianne Hackborn пишет:
As far as ANDROID_ID -- please be aware that some people concerned
about privacy very much do not like applications being able to
retrieve something that uniquely identifies their device that can be
correlated across applications.
Ah, those users again :)
As such, don't be surprised if in the future there appears the ability
to restrict access to ANDROID_ID.
I very strongly recommend not using ANDROID_ID.
The sample LVL implementation uses ANDROID_ID for security (this is how
the duplicates were discovered).
In app billing documentation suggests encrypting purchase data with some
ID unique to the phone.
Tim Bray's blog post from yesterday concludes that for a unique ID, "the
best approach is probably the use of ANDROID_ID".
What is the Android team's position on this then? Is there one?
Implementing trial period support on one's own (since there in none in
LVL or In-App Billing) also needs some kind of unique ID, and the
alternatives (using the primary Google account associated with the
device, or the telephony ID if available) are definitely worse for privacy.
What is your suggestion for this? Generate a unique ID in the
application and back it up using bmgr?
If you want to have settings retained if the user uninstalls and then
re-installs, consider using the backup manager. This also has the
advantage of allowing you to restore the user's settings across devices.
Is that really only 2.2 and up? It seems that my 2.1 phone has bmgr
accessible through adb shell, do you think that's a manufacturer
back-port, or was it really in 2.1, just not documented?
--
Kostya Vasilyev -- http://kmansoft.wordpress.com
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
