"uniqueId" not compliant with Huawei App market Policies

[zhuminjunivan]

Our App was rejected on Huawei AppGallery. Huawei detected that our App obtained ANDROID_ID during initialization, which is not allowed. From the stack information provided by them,

it is found that uniqueId is set in the getConstants method in your open source library, and the ANDROID_ID is obtained using the getUniqueIdSync method.

react-native-device-info/android/src/main/java/com/learnium/RNDeviceInfo/RNDeviceModule.java

Line 192 in 0341ab5

constants.put("uniqueId", getUniqueIdSync());

In order to pass the review, we temporarily annotated the setting of uniqueId and used the getUniqueIdSync method instead in the React Native code.

I hope you can provide a better solution to solve this problem, thank you very much

[mikehardy]

I'm not familiar with the Huawei privacy policy, and it's an image here so I can't easily translate it to learn what their restrictions are, what is allowed, what is not allowed.

I can think of two solutions -

1- just making your workaround more permanent / easier to deal with for you and your team: use patch-package https://github.com/ds300/patch-package/ to save your patch
2- propose a PR here that removes it from constants for privacy reasons and we issue a breaking change here to release it. This could work for me, but only if I knew that would actually pass Huawei privacy guidelines (it would not make sense to issue a breaking change release if it still did not pass, right?)

[zhuminjunivan]

I'm not familiar with the Huawei privacy policy, and it's an image here so I can't easily translate it to learn what their restrictions are, what is allowed, what is not allowed.

I can think of two solutions -

1- just making your workaround more permanent / easier to deal with for you and your team: use patch-package https://github.com/ds300/patch-package/ to save your patch 2- propose a PR here that removes it from constants for privacy reasons and we issue a breaking change here to release it. This could work for me, but only if I knew that would actually pass Huawei privacy guidelines (it would not make sense to issue a breaking change release if it still did not pass, right?)

This is the original:

尊敬的开发者，您好，
关于您的反馈的问题，用户同意隐私前获取了ANDROID_ID，可参考下方调用栈信息，请优化修改。

"stackTrace":["com.learnium.RNDeviceInfo.RNDeviceModule.getUniqueIdSync(RNDeviceModule.java:666)","com.learnium.RNDeviceInfo.RNDeviceModule.getConstants(RNDeviceModule.java:170)","com.facebook.react.bridge.JavaModuleWrapper.getConstants(JavaModuleWrapper.java:129)","com.facebook.react.bridge.queue.NativeRunnable.run(Native Method)","android.os.Handler.handleCallback(Handler.java:955)","android.os.Handler.dispatchMessage(Handler.java:102)","com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:27)","android.os.Looper.loop(Looper.java:228)","com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run(MessageQueueThreadImpl.java:226)","java.lang.Thread.run(Thread.java:933)"]

To the effect, their policy requires users to agree to get ANDROID_ID before our app can get ANDROID_ID. At this time, the user has not had time to agree, and it is obtained during initialization. It is because the setting of uniqueId is caused in the getConstants method. I think you put the uniqueId in the getConstants method for a certain reason, so I'm not going to submit a PR, I'll fix it locally first.

[mikehardy]

Oh, that seems reasonable. I think back when we had it in constants is just from maybe 2015 or something, before anyone was really concerned about privacy and consent etc - I think the Huawei stance is reasonable and a PR to remove it from constants seems like a privacy-focused result, which is a good thing in my opinion. I have no problem issuing breaking changes, my policy is just that when I do, I will always make a nice release note so developers know exactly what is affected, why and what to do. Easy enough in this case. Version numbers are free

[Fred0218]

Any update about this issue?

[mikehardy]

@Fred0218 There plenty yesterday. I see them just above your comment. Does your browser not show them? Do you have a PR to propse?

[stawecki]

@mikehardy Not sure it's worth filing a new issue or renaming this one, but we have the same issue on Google Play:

We’ve identified that your app is using the Segment SDK/Library which collects personal or sensitive data that includes but may not limited to Advertising ID, Android ID identifiers. We do not allow 3rd party SDKs to collect persistent device identifiers that may be linked to other personal and sensitive user data or resettable device identifiers.

I've recently resubmitted an app with a patched version of getUniqueIdSync() that returns an empty string instead, which passed the review ok. So I think there needs to be a decision how to deal with the removal of ANDROID_ID.

While reviewing some analytics packages, I've bumped into some comments from Bugsnag that dealt with this issue:

• Use Advertising ID instead of Android ID. bugsnag/bugsnag-android#83
• Commit: bugsnag/bugsnag-android@437b5de

I believe we can implement a similar solution for people who still rely on this value, but the value would not be unique to the device anymore. This is a better alternative to removing the method completely.

[mikehardy]

@stawecki these seem slightly different. The OP here is saying "we can use the existing implementation, we just cannot do it at startup", that is: the solution is to remove it from constants.

You appear to be saying "we cannot use the current underlying unique ID implementation at all. That's news to me and seems separate. Related, but separate.

I don't see anything in the doc for ANDROID_ID that indicates it should be completely off limits, and it seems like a valid thing for a device info library to expose for those that really do need it. If there is some policy indicating how it should be handled, it would be nice to have a link to the full policy document so that any proposed change fully addresses it

Just to be clear: I am privacy-focused (I actually like these policies as a user) but I also believe that if something is available and can be used responsibly that it is not my job to self-censor / make it unavailable based on vague things if that makes sense? I need to see the real policy positions + clear rules in order to handle it well is all.

[stawecki]

@mikehardy you have a good point, I think I got ahead of myself a bit. The correct solution is to remove it from constants, so it is only ever explicitly called when needed. This seems to be recently enforced judging by communications I've received from Google Play. The related policy is this:

Persistent device identifiers may not be linked to other personal and sensitive user data or resettable device identifiers except for the purposes of

• Telephony linked to a SIM identity (e.g., wifi calling linked to a carrier account), and
• Enterprise device management apps using device owner mode.

These uses must be prominently disclosed to users as specified in the User Data Policy.

Source: https://support.google.com/googleplay/android-developer/answer/10144311

If I understand correctly, any apps obtaining ANDROID_ID not for the purposes described above, will have an issue complying with this policy.

[mikehardy]

Okay - so (warning: assumptions ahead...) if it is out of constants, and a developer asserts that if they call it, they are doing it for those purposes (which are potentially legit purposes and may be done in react-native voip apps or system apps) then...it should pass that policy guidance?

I'm +1 for a PR that moves it out of constants - I haven't done it personally even though it's small because I'm running around launching 20 other releases on other packages but I can help merge of course

[stawecki]

@mikehardy reasonable assumption to test :) I will try this by submitting a build with only the constants patched.

If that works, I'll try to get a PR ready.

[cauyyl]

fork项目，然后修改android/src/main/java/com/learnium/RNDeviceInfo/RNDeviceModule.java 修改804行
csdn 上有个哥们说把import改成require，我感觉不靠谱，我还是提审试一下，要是还过不了，我准备这么干

public String getUniqueIdSync() { return "no-android-id"; }

fork this project ,and edit android/src/main/java/com/learnium/RNDeviceInfo/RNDeviceModule.java line 804 to， i am trying

public String getUniqueIdSync() { return "no-android-id"; }

[stawecki]

@cauyyl I've tried a similar patch on Google Play and it worked fine. We're now trying removing from constants, so the ANDROID_ID can still be fetched, but only with explicit consent.

[mikehardy]

@fengqingyun2008 has posted what I would say is a preliminary PR for this but

a) we still do not have authoritative test results from google play store that this is sufficient
b) the PR is perhaps 10% of the work needed so either that PR needs to be thorough or someone else affected by this should check the review comment there and post a complete shift of the uniqueId out of constants to a regular getter

[stawecki]

@mikehardy re: a) I have initial results of the submitted build with an identical change as #1428 and so far no issues with Google Play (it has passed review). I have another project that is affected, so I'll try that one as well. It seems this patch is correct and we can go ahead. If I see otherwise, I'll post here.

[mikehardy]

Great! One project is probably sufficient, so then what we need is a "complete 1428" - that is, actually remove it from constants consistently in all spots, then off we go I think

[cauyyl]

fork项目，然后修改android/src/main/java/com/learnium/RNDeviceInfo/RNDeviceModule.java 修改804行 csdn 上有个哥们说把import改成require，我感觉不靠谱，我还是提审试一下，要是还过不了，我准备这么干

public String getUniqueIdSync() { return "no-android-id"; }

fork this project ,and edit android/src/main/java/com/learnium/RNDeviceInfo/RNDeviceModule.java line 804 to， i am trying

public String getUniqueIdSync() { return "no-android-id"; }

worked for me, i hope the main pr can solve this problem directly thx

[zhuminjunivan]

+1，Huawei failed to pass the audit due to the same problem

and CodePush

[mikehardy]

DO NOT +1, Please please 🙏

POST A PR then I can merge.

I left detailed comments on someone's attempte at #1428 - please read those and post a good PR and I can merge.

+1s are meaningless when it comes to open source, they actually have negative value because they make people look, and they make you feel like you did something but really nothing was done

But I can merge a PR and that's a real advance! Cheers

[rndi-bot]

🎉 This issue has been resolved in version 10.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀