Hey there! Let's tackle your two questions around telling Android emulators apart from real devices, and how to get unique identifiers for this purpose. I've worked through plenty of these scenarios, so here's what you need to know:

There are several categories of parameters you can check to spot the difference. Let's go through them one by one:

1. 系统属性与Build信息 #

These are the most straightforward checks, since emulators often expose telltale signs in their system build data:

• 制造商与品牌: 大部分模拟器会把制造商设为Genymotion、Android Studio、BlueStacks等特定值，而真机一般是Samsung、Google、Xiaomi等主流品牌。你可以通过Build.MANUFACTURER和Build.BRAND获取这些值。
• 设备型号: 模拟器的型号通常带有"emulator"、"sdk_gphone"、"VirtualBox"这类关键词，比如Build.MODEL返回"Android SDK built for x86"。
• 硬件信息: Build.HARDWARE在模拟器中常返回"goldfish"、"ranchu"，而真机是对应芯片的硬件代号，比如"qcom"（高通）、"exynos"（三星）。
• 产品名称: Build.PRODUCT在模拟器中可能是"sdk_x86"、"emulator_x86"，真机则是对应机型的产品名，比如"pixel_6_pro"。

2. 硬件特征与传感器 #

Real devices have actual hardware components that emulators either fake or don't support:

• 传感器存在性: 尝试获取加速度计、陀螺仪、磁力计等传感器，模拟器可能返回null或者固定的模拟数据。比如用SensorManager.getSensorList(Sensor.TYPE_ACCELEROMETER)，如果返回空列表或者数据长期不变，大概率是模拟器。
• 相机信息: 模拟器的相机通常是虚拟的，你可以检查相机的参数，比如CameraCharacteristics.LENS_FACING对应的设备数量，或者查看相机的分辨率是否是标准的虚拟值。
• 电池状态: 模拟器的电池状态往往是固定的（比如一直显示100%电量，充电状态不变），而真机的电池数据会随使用变化。可以通过BatteryManager获取BATTERY_STATUS和BATTERY_LEVEL来判断。

3. 系统行为与环境 #

Emulators behave differently in some system-level aspects:

• 文件系统路径: 模拟器中可能存在一些特定的文件路径，比如/system/lib/libc_malloc_debug_qemu.so，而真机不会有这类QEMU相关的文件。
• 网络特征: 模拟器的网络接口可能有特定的名称，或者访问某些内部地址（比如10.0.2.2是模拟器指向主机的地址），不过这个要结合场景判断，因为有些真机也可能用类似的内网地址。
• Root状态: 很多模拟器默认是rooted的，而大部分普通真机（非用户自行root）是未root状态。你可以通过检查/system/bin/su是否存在来判断，但注意有些用户会root真机，所以这个不是绝对的。

The key here is that no single parameter is 100% reliable (emulators can fake most individual values), but combining multiple checks will give you a high confidence result. Here's how to approach it:

1. 组合多个参数进行判断 #

Instead of relying on one value, create a scoring system or a checklist. For example:

• Check if Build.MANUFACTURER is in a list of known emulator manufacturers.
• Verify if sensors return valid, changing data.
• Check for the presence of QEMU-specific files.
• Cross-reference battery status behavior.

If most of these checks point to an emulator, you can be reasonably sure it's not a real device.

2. 使用相对稳定的唯一标识（注意权限限制） #

If you need a unique identifier to track the device (while distinguishing emulator vs real), here are options:

• Android ID: You can get it via Settings.Secure.getString(getContentResolver(), Settings.Secure.ANDROID_ID). It's a 64-bit string unique per user on the device. Note that it can change if the user resets their device, and emulators might generate a new one each time they're launched.
• Advertising ID: If your goal is ad-related tracking, the Advertising ID (from Google Play Services) is a good option. It's resettable by the user, but it's consistent across apps on the same device. Emulators can also have this, but you can combine it with other checks to flag emulators.
• Combined Hardware IDs: You can create a hash of multiple hardware-related values (like Build.BOARD, Build.DISPLAY, Build.FINGERPRINT) to generate a unique identifier. Just keep in mind that some of these values can be faked by emulators, so again, combine with other checks.

3. 注意权限与隐私限制 #

• IMEI/MEID: These are unique to real devices, but starting from Android 10 (API 29), you need the READ_PRIVILEGED_PHONE_STATE permission, which is only granted to system apps. So this is not feasible for most third-party apps.
• Serial Number: Build.SERIAL is deprecated in API 26, and accessing it requires the READ_PHONE_STATE permission, which users might be reluctant to grant.

Quick Code Snippet Example #

Here's a simple function to check for common emulator signs:

public static boolean isEmulator(Context context) {
    String manufacturer = Build.MANUFACTURER;
    String model = Build.MODEL;
    String hardware = Build.HARDWARE;
    
    // Check manufacturer and model
    boolean isKnownEmulator = manufacturer.equalsIgnoreCase("Genymotion")
            || manufacturer.equalsIgnoreCase("Android Studio")
            || model.contains("emulator")
            || model.contains("sdk_gphone");
    
    // Check hardware
    boolean isEmulatorHardware = hardware.equalsIgnoreCase("goldfish")
            || hardware.equalsIgnoreCase("ranchu");
    
    // Check for QEMU file
    boolean hasQemuFile = new File("/system/lib/libc_malloc_debug_qemu.so").exists();
    
    // Check sensor availability (example with accelerometer)
    SensorManager sensorManager = (SensorManager) context.getSystemService(Context.SENSOR_SERVICE);
    boolean hasValidSensor = sensorManager.getSensorList(Sensor.TYPE_ACCELEROMETER).size() > 0;
    
    return isKnownEmulator || isEmulatorHardware || hasQemuFile || !hasValidSensor;
}

Just remember, no method is foolproof—emulators are getting better at faking real device characteristics. But combining these checks will cover most cases.

内容的提问来源于stack exchange，提问作者Bharat Patil