# Android_CN_OAID: Device Identifiers for Apps That Cannot Use the MSA SDK

> Android_CN_OAID is a Java library that reads OAID, AAID and legacy Android identifiers through vendor interfaces. It exists because individual developers are not eligible for the official MSA SDK, and its own README says so.

**gzu-liyujiang/Android_CN_OAID** — 安卓设备唯一标识解决方案，可替代移动安全联盟（MSA）统一 SDK 闭源方案。包括国内手机厂商的开放匿名标识（OAID）、海外手机平台的安卓广告标识（AAID），另外也提供了 IMEI/MEID、AndroidID、WidevineID、PseudoID、GUID 等常见的设备标识的获取方法。

- Repository: https://github.com/gzu-liyujiang/Android_CN_OAID
- Website: https://gzu-liyujiang.github.io/Android_CN_OAID/
- Stars: 2,869 · Forks: 468
- Language: Java
- License: NOASSERTION
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/gzu-liyujiang-android-cn-oaid

## The gap Android_CN_OAID fills for individual developers

Android has no single stable device identifier that survives a reinstall and is available to every app. Google's Advertising ID is not served on devices without Google Play services, which covers much of the Chinese market. The Mobile Security Alliance (MSA) publishes a unified SDK, distributed as miit_mdid_xxx.aar, that asks each domestic vendor's system service for an OAID. The README states the project's own position plainly: it is aimed at individual developers, who are not eligible to use the MSA SDK, and enterprise apps should apply for the MSA SDK instead. That is an unusual thing for a library to say about itself, and it is the honest framing. The library also covers AAID on overseas platforms, and exposes IMEI, MEID, AndroidID, WidevineID, PseudoID and GUID through the same facade. If you only need a random per-install value, you do not need this project at all.

## How OAID resolution works across vendor interfaces

The mechanism is a set of AIDL bindings to vendor services, wrapped behind one class. The repository contains an aidl/ directory, and the bundled ProGuard rules keep classes under namespaces such as repeackage.com.uodis.opendevice.aidl, repeackage.com.heytap.openid, repeackage.com.asus.msa.SupplementaryDID, repeackage.com.bun.lib, repeackage.com.samsung.android.deviceidservice and repeackage.com.zui.deviceidservice. Those are the vendor-specific endpoints the library binds to at runtime. Note the spelling of repeackage: the README calls it a historical leftover, and the keep rules must match it exactly or obfuscation will break the binding. Since version 4.2.5.1 the project depends on Huawei's official ads-identifier SDK and Honor's, rather than reimplementing those two vendors. The README admits the maintainer did not repackage Huawei's SDK to avoid class conflicts, which is why coexistence with the MSA SDK requires exclusions. Resolution is asynchronous: DeviceID.getOAID delivers a result or an error through an IGetter callback, and DeviceID.supportedOAID reports whether either OAID or AAID is available at all. Formats differ per vendor, so the README suggests hashing the result with MD5 or SHA1 to normalize it.

## Installing Android_CN_OAID from JitPack and making the first call

The library is published on JitPack, with a mirror build on Gitee. For Gradle 7.0 and above, the README places the repositories in settings.gradle. The Huawei and Honor entries are required because the library pulls their ads-identifier artifacts.

```groovy
dependencyResolutionManagement {
    repositories {
        maven { url 'https://jitpack.io' }
        maven { url 'https://developer.huawei.com/repo' }
        maven { url 'https://developer.hihonor.com/repo' }
    }
}
```

Then declare the dependency. The README writes the version as a placeholder, so you substitute the release you want; the most recent one listed is 4.2.17. The two runtimeOnly lines bring in the vendor SDKs.

```groovy
dependencies {
    implementation 'com.github.gzu-liyujiang:Android_CN_OAID:最新版本号'
    runtimeOnly "com.huawei.hms:ads-identifier:3.4.62.300"
    runtimeOnly "com.hihonor.mcs:ads-identifier:1.0.2.301"
}
```

For Gradle below 7.0 the same three repositories go into the allprojects block of build.gradle. A Gitee coordinate, com.gitee.li_yu_jiang:Android_CN_OAID, is documented as an alternative source.

Calling it means registering first. The README shows registration in Application#onCreate, guarded by whether the user has agreed to the privacy policy, and notes that you should not call it before consent.

```java
@Override
public void onCreate() {
    super.onCreate();
    if (privacyPolicyAgreed) {
        DeviceIdentifier.register(this);
    }
}
```

After that, DeviceIdentifier.getOAID(this) returns the value synchronously, or DeviceID.getOAID(this, new IGetter() { ... }) delivers it through onOAIDGetComplete and onOAIDGetError. The README's guidance is to collect several identifiers and reconcile them server-side using a Byzantine fault tolerance scheme, rather than trusting any single value. What you should expect in practice is that onOAIDGetError fires on devices where no vendor service answers.

## Permissions, deprecations and the cases where it fails

Since 4.1.1 the library's manifest adds READ_PHONE_STATE, WRITE_SETTINGS and WRITE_EXTERNAL_STORAGE to support older Android versions. That is a real cost: an app that only wants OAID inherits permissions it does not need. The README shows how to remove them with tools:node="remove" in AndroidManifest.xml, and describes this as following the minimum necessary principle. Do it, because a privacy review will ask. Versions 4.1.1 through 4.1.3 have a documented problem on Android 11 and above when the Gradle plugin does not target API 29 or higher, affecting dynamic permission requests. WidevineID is deprecated as of 4.2.7, and the README is blunt about why: it is of little use and on some phones can cause freezing or crashes. IMEI only works below Android 10 and may be empty regardless. PseudoID is generated from hardware information, is never empty, and has a high chance of collisions, which makes it unsuitable as a primary key. GUID is random and therefore resets with the app. This is a library for collecting candidates, not for producing one authoritative identifier, and any design that treats a single call as ground truth is misusing it.

## Coexistence with the MSA SDK and what to exclude

If your app already ships the MSA SDK, the two will collide over Huawei's ads-identifier classes, because both depend on them. The README's workaround is a Gradle exclusion on the Android_CN_OAID dependency, commented out by default so you can enable it. The same applies to Honor's artifact. The README also notes that if the Huawei SDK fails to download or fails to compile, you can add the repository and runtimeOnly line manually in build.gradle. This is the least polished part of the integration story, and it is worth reading the CHANGELOG before upgrading across a version where the vendor dependency changed.

## How this differs from the MSA SDK and from Google's Advertising ID

The MSA SDK is a binary AAR distributed under an agreement, and the README directs enterprise apps to it. The practical difference is not technical capability but access: MSA requires a signed agreement that individual developers cannot obtain, while Android_CN_OAID is consumed as an ordinary JitPack dependency. The trade-off is support surface. MSA is maintained by the body that defines the interface, so new vendors and format changes arrive through a single channel. Android_CN_OAID maintains its own bindings per vendor and, for Huawei and Honor, delegates to those vendors' official SDKs. On the overseas side, Google's Advertising ID through Play services is the conventional choice; this library's DeviceID.getByGms path targets that service, and DeviceID.getByMsa targets the MSA route, so you can select a strategy rather than accept one. The README also links a DMCA takedown against another MSA-related repository and states that this project's code is original, derived from Beijing Shuzilm's public code plus vendor interfaces. That history explains why the project exists outside the official channel, and it is also why the licence file is marked NOASSERTION in the repository metadata: read LICENSE and NOTICE yourself before commercial use, and treat the linked issue discussion as context rather than legal advice.

## Conclusion

Adopt it if you are an individual developer who needs OAID or AAID and cannot sign the MSA SDK agreement. Do not adopt it if you are a company that qualifies for the official miit_mdid AAR, or if you need a stable identifier without server-side reconciliation. Before shipping, verify which permissions the manifest merge actually adds, which vendor paths return values on your target devices, and whether your Gradle setup resolves the Huawei and Honor repositories.

## FAQ

### What is Android_CN_OAID used for?

It reads OAID and AAID plus common Android identifiers such as IMEI, AndroidID, PseudoID and GUID through one Java API. The README positions it as an alternative to the MSA unified SDK for individual developers.

### Can Android_CN_OAID replace the MSA SDK for a company app?

The README says no: its purpose is individual developers' apps, and enterprise apps should apply for the MSA SDK. It also notes the library can coexist with the MSA SDK if you exclude the Huawei and Honor ads-identifier artifacts.

### Why does Android_CN_OAID add READ_PHONE_STATE and WRITE_SETTINGS?

Since version 4.1.1 the manifest includes READ_PHONE_STATE, WRITE_SETTINGS and WRITE_EXTERNAL_STORAGE to support older Android versions. The README shows removing them with tools:node="remove" if your app does not use IMEI or GUID.

### Is Android_CN_OAID still maintained?

The repository is not archived and the last push was on 2026-05-18, with release 4.2.17 on 2026-03-21. The CHANGELOG is the place to check what changed between versions.

## Sources

- [gzu-liyujiang/Android_CN_OAID on GitHub](https://github.com/gzu-liyujiang/Android_CN_OAID)
- [Issues](https://github.com/gzu-liyujiang/Android_CN_OAID/issues)
- [Project website](https://gzu-liyujiang.github.io/Android_CN_OAID/)
- [README](https://github.com/gzu-liyujiang/Android_CN_OAID/blob/master/README.md)
- [Releases](https://github.com/gzu-liyujiang/Android_CN_OAID/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/gzu-liyujiang-android-cn-oaid