4

I require the list of fixed properties of android.os.Build class. I've obtained the list from here I bold those that I know are fixed. By fix I mean no change by firmware update, reset factory, ...

  1. android.os.Build.VERSION.RELEASE //The current development codename, or the string "REL" if this is a release build.

  2. android.os.Build.BOARD //The name of the underlying board, like "goldfish".

  3. android.os.Build.BOOTLOADER // The system bootloader version number.

  4. android.os.Build.BRAND //The brand (e.g., carrier) the software is customized for, if any.

  5. android.os.Build.CPU_ABI //The name of the instruction set (CPU type + ABI convention) of native code.

  6. android.os.Build.CPU_ABI2 // The name of the second instruction set (CPU type + ABI convention) of native code.

  7. android.os.Build.DEVICE // The name of the industrial design.

  8. android.os.Build.DISPLAY //A build ID string meant for displaying to the user

  9. android.os.Build.FINGERPRINT //A string that uniquely identifies this build.

  10. android.os.Build.HARDWARE //The name of the hardware (from the kernel command line or /proc).

  11. android.os.Build.HOST

  12. android.os.Build.ID //Either a changelist number, or a label like "M4-rc20".

  13. android.os.Build.MANUFACTURER //The manufacturer of the product/hardware.

  14. android.os.Build.MODEL //The end-user-visible name for the end product.

  15. android.os.Build.PRODUCT //The name of the overall product.

  16. android.os.Build.TAGS //Comma-separated tags describing the build, like "unsigned,debug".

  17. android.os.Build.TYPE //The type of build, like "user" or "eng".

  18. android.os.Build.USER

Please help me complete the list

Community
  • 1
  • 1
Mohsen Afshin
  • 13,273
  • 10
  • 65
  • 90

3 Answers3

16

If you look at the source code to Build, you will see that all of these values -- including those you have in bold -- come from system properties files. Hence, any of these values can be modified by ROM modders or the original device manufacturer as they see fit.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • Your note is true, but there should be some of them that logically stay fixed like the Model, that no company would change it even on firmware update – Mohsen Afshin Nov 14 '12 at 13:18
  • 4
    @MohsenAfshin: So? Device manufacturers do not always behave logically. For example, `MODEL` may not stay fixed due to a manufacturer losing a trademark infringement suit. You say that you want "100% correct answer", but there is none, other than "any properties can change". Assuming anything else is pure guesswork and likely to be wrong on occasion. – CommonsWare Nov 14 '12 at 13:28
2

I'm not going to address the woes with consistencies of Build as Mark has illustrated why there isn't a guaranteed answer. Instead I want to respond to what your purpose and intent is.

If I understand correctly, you are trying to uniquely identify a single device. I point you firstly to this answer, from which you can simply conclude that a generic solution is not possible. Either resetting factory defaults or switching SIM cards (if the device has one) will change any sort of unique ID and fool your app into thinking it's a different user.

You need to rethink what you're trying to accomplish. Why do you need to uniquely identify a device? If you're trying to identify a user, then this mindset doesn't cope for multiple devices either. This is now especially the case with Jellybean 4.2, where a device may support multiple users. See also this insightful blog post on the Android Developers Blog.

Can you have the user attach his Google account? Or account for your own service? If you can identify a user, it is then trivial to identify individual devices through UUID.randomUUID().

Community
  • 1
  • 1
Paul Lammertsma
  • 37,593
  • 16
  • 136
  • 187
  • All you said is true, but I can't rely on Google account since not everybody may setup a Google account on his/her android device, and also the multiple user feature of 4.2 is not a problem, I need to make a mix of Build properties that is almost unique, you know I want them to be fixed as much as possible even though as Mark said all of them can even change – Mohsen Afshin Nov 15 '12 at 12:11
  • 2
    I would suggest generating a UUID and storing it in the `SharedPreferences`. You might alternatively consider storing it on the external storage, but I would urge you not to do that because it pollutes the storage card, doesn't work when no external storage is available, doesn't cope with switching SD cards and may be manipulated by the user. – Paul Lammertsma Nov 15 '12 at 13:08
  • 1
    I want the Unique ID be regenerate able on the device and at the first place this is the reason that I'm looking for fixed properties so that I don't get a new ID each time – Mohsen Afshin Nov 15 '12 at 14:38
  • 1
    I have looked into this in quite some detail for a client in the past, and the only way of doing this (on unrooted devices) is by storing a UUID in both the external storage and shared preferences. If the shared preferences ID is absent, it then reads the one from the external storage in order to cope with unavailable storage cards, switching SD cards or manipulation by the user. I'm afraid there simply isn't a different solution. – Paul Lammertsma Nov 19 '12 at 09:07
1

If I understand correctly (regarding your follow-up comment) you want to identify a device without integrating some kind of registration or login mechanism.

Instead of implementing yout own ID computation algorithm I would suggest using an OpenUDID implementation for android (see https://github.com/vieux/OpenUDID).

Andreas Klöber
  • 5,855
  • 2
  • 27
  • 20
  • This OpenUDID does nothing more than checking Android_ID and if is not all it generate a random one ( OpenUDID = new BigInteger(64, random).toString(16); ). We know Android_ID is not stable and how this RANDOM number is persistent and regenerate able from scratch on the device ???!!! – Mohsen Afshin Nov 18 '12 at 13:28
  • Yes, ANDROID_ID is checked and a random ID is generated as a fallback. The derived ID is stored in private SharedPreferences and synchronized between all apps that use OpenUDID (the native ANDROID_ID would be shared across all apps too). Nevertheless if all apps that use OpenUDID are uninstalled the first app to be reinstalled gets a new ID if the fallback mechanism had to be used. Furthermore the ID will not survive a factory reset but I'd consider that a feature as a user would not want that anything tied to himself or an account of him remains after a factory reset to e.g. sell the device. – Andreas Klöber Nov 18 '12 at 15:58
  • 1
    Since the id is used for unique installation of the software, it must be unique and regenerate able even after factory reset – Mohsen Afshin Nov 18 '12 at 18:22