Do you use any sort of a naming convention, so you can identify what's what for later comparison purposes? I'm thinking something a bit along the lines of URL schemes (imsi:... or even imsi-v10:... for an IMSI reported by API Level 10, where the ... is the actual IMSI value).
For example, it may be that an upgrade to the OS changes which of the rules fires for that device, because they added support for something they didn't have earlier. On Mon, Dec 5, 2011 at 9:49 AM, Streets Of Boston <[email protected]> wrote: > http://android-developers.blogspot.com/2011/03/identifying-app-installations.html > This link suggests and advises identifying accounts, not specific devices. > > However, sometimes you can't get around it. E.g. if you have an app that > publishes digital content under DRM, you usually have to be able to identify > individual devices. > > This is what we do at my company: > > First, try to read one that you have saved in the last step of this > procedure. If found, return this one. > Read the telephony id. > This will work for every phone and tablet with a SIM card and such. Since > most Android devices that have Android 2.3 or lower are phones, you have > covered a big chunk of your install base. > If available, use this one. Save it somewhere for point (1.) > Read the Serial number (android.osb.Build.SERIAL) > This one is only available on 2.3x devices and higher. This means you'd have > to use java reflection to get at it if your app must run on Android 2.2 or > lower. > If available, use this one. Save it somewhere for point (1.) > Now you have covered a laaarge chunk of your install-base. 100% of all > devices running 2.3x and higher. The only devices that are still can be > problematic are Android 2.2. (or lower) devices that are WiFi only: > Read the MAC address of the device > Since the device is WiFi only, it is their only way to get a data-connection > and they just downloaded your app: It is likely that the WiFi is enabled and > querying the MAC address very likely succeeds. > If available, use this one. Save it somewhere for point (1.) > If everything else fails, generate a Random number/string and use this as > your unique-id. > Save it somewhere for point (1.) > > I think this will cover 99.9999% of your install base. However, it is not > full-proof. This means that you'd have to design a way to allow the users to > reset their device-id on your servers, either through some online form or > through customer service. > > -- > 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 -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Warescription: Three Android Books, Plus Updates, One Low Price! -- 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
