I got this rejection notice: Your app contains the a.gray.inventor.a virus, which may bring security risks to user devices.
After talking with them for over a week, this is their answer: **Dear Developer,
Is there a way to fix this issue? Is there a component that I use in the app that triggers it?
Help, thank you!
see this ai advice on what to do
Try the fix and let us know what happens.
Hello, thank you. But the answers are very vague; hard to understand. Why can MIT have a solution already? It is just not me!
You did not share your code Oscar, so who knows what extensions you are using or what your app does that gets the false positive tripped in your app. Most likely “
so Huawei are upset you are using SMS perhaps and the way you use the app? What have you tried?
Hello, and thank you. I haven’t tried anything. No idea what to do. If I do whatever, it’s just going to get rejected…
Someone at MIT knows the solution; it has to be!
Check your screens for use of the Messaging component?
List the extensions you use?
Export and post your aia file?
Show us your unchive summary?
Hello, and thank you.
The extensions are:
@Oscar_Medina I found no issue in your AIA file. It’s auto deep check by Huawei, appeal to them- What to Say to Huawei Right Now
"I have reviewed my APK manifest in full. It contains zero SMS-related permissions (no SEND_SMS, RECEIVE_SMS, or READ_SMS). Under Android's security model, an application is physically incapable of sending or intercepting SMS without these declared permissions. The detection appears to be triggered by the MIT App Inventor runtime library, which bundles unused component classes in its DEX output — but these classes cannot execute without the corresponding manifest permissions. I request escalation to a senior security reviewer with the attached manifest as evidence."
Attach your Manifest file + APK + builder link https://ai2.appinventor.mit.edu with your appeal.
These are not extensions, you can call them components. Extension means any component you imported from outside into the App Inventor.
Thank you!
I will contact Huawei. When I get a response, I will update this post.
But:
The detection appears to be triggered by the MIT App Inventor runtime library, which bundles unused component classes in its DEX output —
Then, If that seems to be the issue, MIT should look into it.
eAcademy is correct that the manifest is clean, but it might help to understand exactly why Huawei flags the APK so that the appeal makes a stronger case.
App Inventor's build pipeline splits the work into two layers. The first layer decides which permissions go into AndroidManifest.xml. That layer is selective. LoadComponentInfo.java (inside loadJsonInfo) checks each component type against the set of types the project actually uses, and if a component is absent it skips all its permissions. CreateManifest.java then writes that filtered set into the manifest. Your component list does not include Texting, so SEND_SMS and RECEIVE_SMS do not get added. Your app has zero SMS permissions in the manifest and that is correct.
The second layer packages the compiled Java classes into the DEX file that ships inside the APK. That layer is not as selective. RunD8.java feeds the entire AndroidRuntime.jar into the dexer as a single monolithic input. AndroidRuntime.jar contains every component class that App Inventor ships, including Texting.class and SmsBroadcastReceiver.class, regardless of whether your project uses the Texting component. In the main app build path, there is no tree-shaking step that strips unused classes before dexing.
Huawei's scanner appears to go beyond the manifest. The behavior is consistent with static analysis of the DEX bytecode, where SmsManager API calls, the SMS_RECEIVED intent filter string, and SMS-handling method bodies from Texting.class are all present. That pattern is consistent with what Huawei labels a.gray.inventor.a.
The SMS capability Huawei described is not available to this app. Android enforces SEND_SMS and RECEIVE_SMS at the platform level, so without those permissions in the manifest the app cannot send or receive text messages through those code paths, no matter what the bytecode contains. The classes are physically present but the protected behavior is not granted.
For the appeal, in addition to the manifest argument eAcademy suggested, you could point Huawei to the App Inventor source code on GitHub (it is fully open source under Apache 2.0) and explain that AndroidRuntime.jar is a shared runtime library that bundles all component classes for every App Inventor app. The SMS-related classes exist in the JAR for apps that do use the Texting component, but your posted component list does not include Texting and the manifest shows the SMS permissions are absent.
A longer-term fix on the App Inventor side would be to add R8 or ProGuard tree-shaking to the build pipeline so that unused component classes are stripped from the DEX before packaging. That should prevent this kind of false positive.
Thank you. After reading your knowledgeable input, you came up with a solution at the end. How difficult is that for MIT to implement? I haven't heard from Huawei on my last reply, but after a few earlier replies from them, they seem to be reluctant to insist that it is a virus.
I am wondering how many applications built by MIT were approved by Huawei! And so, how do these developers avoid it? Huawei not to label the app a.gray.inventor.a. Then it seems that someone in this community knows the workaround to get their apps approved, and keeps it a "secret."
Huawei should be whitelisting the "virus" (a.gray.inventor.a - their finding) not your app. It is their problem, not MITs.
Install a stock android os, or disable the Huawei anti-virus, problem solved.
Thank you. Can you please elaborate on the solution?
The first is for you to resolve with Hauwei.
The second and third are outside of my experience. (Huawei devices)
Hello,
This was Huawei's response:
Dear Developer,
Thank you for waiting after Tech. With team feedback, the detected virus can still bypass the permission requirement to receive and send SMS. Thus, please check again and remove relevant coding or replace other coding.
Best Regards,
HUAWEI Developers
Maybe this will help you:
While I'm not opposed to changing how the build system works, such a change is nontrivial (i.e., it should not break any existing apps, including those with extensions), and is simply not a risk-effort-reward tradeoff worth making from our end. Given that we already publish our companion app (built with App Inventor) through the Google Play store and comply with all of their guidelines, I do not foresee a reasonable pathway for our team to also incorporate demands from other storefronts.
Ok, you're the boss!
Thank you. I will try that.