Identifying App Installations(安裝APP時產生獨一無二user_id)

woff

[The contents of this post grew out of an internal discussion featuring many of the usual suspects who’ve been authors in this space. — Tim Bray]

In the Android group, from time to time we hear complaints from developers about problems they’re having coming up with reliable, stable, unique device identifiers. This worries us, because we think that tracking such identifiers isn’t a good idea, and that there are better ways to achieve developers’ goals.

在Android 團隊，我們聽到很多投訴開發者在裝置上可靠度、穩定的問題，這讓我們憂心不已，因為獨一無二的軌跡不是個好主意，所以我們換個方法來達到開發目標

Tracking InstallationsAPP安裝軌跡

It is very common, and perfectly reasonable, for a developer to want to track individual installations of their apps. It sounds plausible just to call TelephonyManager.getDeviceId() and use that value to identify the installation. There are problems with this: First, it doesn’t work reliably (see below). Second, when it does work, that value survives device wipes (“Factory resets”) and thus you could end up making a nasty mistake when one of your customers wipes their device and passes it on to another person.

在開發者要分開安裝其他APP時，這是非常一般和完美的理由，這聽起來似乎像是TelephonyManager.getDeviceId() 和使用獨一無二的安裝ID，那裏有相當多的問題，

第一，運作不可靠(看下面)

第二：當工作中

當值存在時，當有一個使用者在在進行裝置wipes(工廠模式)和非常討厭的結果

To track installations, you could for example use a UUID as an identifier, and simply create a new one the first time an app runs after installation. Here is a sketch of a class named “Installation” with one static method Installation.id(Context context). You could imagine writing more installation-specific data into the INSTALLATION file.

在軌跡安裝時，舉例來說：安裝後第一時間可以簡單產生APP唯一UUID，這有一草圖像是名叫“Installation”用靜態方法產生Installation.id(Context context).
你可以想像寫入一個安裝詳細資料到INSTALLATION檔案

1. public class Installation {
   
2.     private static String sID = null;
   
3.     private static final String INSTALLATION = "INSTALLATION";
   
4. 
   
5.     public synchronized static String id(Context context) {
   
6.         if (sID == null) {  
   
7.             File installation = new File(context.getFilesDir(), INSTALLATION);
   
8.             try {
   
9.                 if (!installation.exists())
   
10.                     writeInstallationFile(installation);
    
11.                 sID = readInstallationFile(installation);
    
12.             } catch (Exception e) {
    
13.                 throw new RuntimeException(e);
    
14.             }
    
15.         }
    
16.         return sID;
    
17.     }
    
18. 
    
19.     private static String readInstallationFile(File installation) throws IOException {
    
20.         RandomAccessFile f = new RandomAccessFile(installation, "r");
    
21.         byte[] bytes = new byte[(int) f.length()];
    
22.         f.readFully(bytes);
    
23.         f.close();
    
24.         return new String(bytes);
    
25.     }
    
26. 
    
27.     private static void writeInstallationFile(File installation) throws IOException {
    
28.         FileOutputStream out = new FileOutputStream(installation);
    
29.         String id = UUID.randomUUID().toString();
    
30.         out.write(id.getBytes());
    
31.         out.close();
    
32.     }
    
33. }

複製代碼

Suppose you feel that for the needs of your application, you need an actual hardware device identifier. This turns out to be a tricky problem.

假設你需要確實的硬體裝置的ID，這是棘手的問題

In the past, when every Android device was a phone, things were simpler: TelephonyManager.getDeviceId() is required to return (depending on the network technology) the IMEI, MEID, or ESN of the phone, which is unique to that piece of hardware.

在過去，Android手機相當簡單，TelephonyManager.getDeviceId()只需要返回(網路功能獨立)，電話上的IMEI, MEID, or ESN都是唯一

However, there are problems with this approach:

然而現在有其他問題產生

• Non-phones: Wifi-only devices or music players that don’t have telephony hardware just don’t have this kind of unique identifier.
• 無電話：只有Wifi的裝置或是音樂並無應提其他技術，所以也無為一ID
• Persistence: On devices which do have this, it persists across device data wipes and factory resets. It’s not clear at all if, in this situation, your app should regard this as the same device.
• 持久性：裝置要完成這，堅持有wipes 及 factory resets(工廠模式)，在這情況如果沒清理乾淨，APP可能無法正常運作
• Privilege:It requires READ_PHONE_STATE permission, which is irritating if you don’t otherwise use or need telephony.
• 權力：他需要READ_PHONE_STATE 權限去激發，除此以外你不需要使用及需要專業技術
• Bugs: We have seen a few instances of production phones for which the implementation is buggy and returns garbage, for example zeros or asterisks.
• 臭蟲：
  

Mac Address

It may be possible to retrieve a Mac address from a device’s WiFi or Bluetooth hardware. We do not recommend using this as a unique identifier. To start with, not all devices have WiFi. Also, if the WiFi is not turned on, the hardware may not report the Mac address.

Serial Number

Since Android 2.3 (“Gingerbread”) this is available via android.os.Build.SERIAL. Devices without telephony are required to report a unique device ID here; some phones may do so also.

ANDROID_ID

More specifically, Settings.Secure.ANDROID_ID. This is a 64-bit quantity that is generated and stored when the device first boots. It is reset when the device is wiped.

ANDROID_ID seems a good choice for a unique device identifier. There are downsides: First, it is not 100% reliable on releases of Android prior to 2.2 (“Froyo”). Also, there has been at least one widely-observed bug in a popular handset from a major manufacturer, where every instance has the same ANDROID_ID.

Conclusion

For the vast majority of applications, the requirement is to identify a particular installation, not a physical device. Fortunately, doing so is straightforward.

There are many good reasons for avoiding the attempt to identify a particular device. For those who want to try, the best approach is probably the use of ANDROID_ID on anything reasonably modern, with some fallback heuristics for legacy devices.

文章出處