com.mediatek "bootloop" statement and "share apk" requests in the list

[qumuq-til]

List your packages

The current entry for com.mediatek says "Cause Bootloop". That isn't the case in my experience on Ulefone Armor 18T Ultra, and it's not known who or on what device provided that description. So I wonder going forward how to best address such claims in PR corrections: should I simply remove such entries completely if it worked for me, or should I mention that "it used to cause a bootloop for someone but doesn't on Armor, Android 13" etc etc.

Also as I understand those "share APK" requests are too very old, coming from the parent project, and even there shared APKs were usually shrugged off. I wonder if we should simply remove "can someone share the apk" lines from all entries that contain it.

Acknowledgements

• [X] This issue is not a duplicate of an existing one.
• [X] I have chosen an appropriate title.
• [X] All requested information has been provided properly.

[AnonymousWP]

You can use Git Blame for that. I see @Blitz517 added/modified that description. Usually, we keep the removal but just add "doesn't bootloop on ".

As of sharing APKs: yes, this was not done in the parent project, but here we share APKs via GitHub Discussions: https://github.com/Universal-Debloater-Alliance/universal-android-debloater-next-generation/discussions/categories/apk-sharing

[qumuq-til]

So speaking about mediatek apks specifically, are you done with those? Have been shared more than a few times in the past, yet some mediatek entries still ask for those apks.

What is the stance towards documenting everything for this project? For example, I have a stock flashlight app (and a bunch of other obvious user-oriented apks) that is "Unknown", should I try to provide info for all of them or only for those that potentially raise alarms?

[Blitz517]

From the old days on android com.mediatek caused bootloop, but if something has changed now, we can tell them that on your phone it does not cause bootloop. Anyway there's on internet any debloat list that recommend removing that? maybe not.

[qumuq-til]

My approach may be different: remove everything and work your way backwards until everything is stable.

There's another issue with debloating, that it may give a false impression that you're fully in control. While in reality, as mediatek's Duraspeed utility demonstrates, there's an underlying system service which is baked into the base and is not an apk. You can disable and uninstall everything with uad-ng, but that app killer service will keep operating. Maybe that general idea could be mentioned on the project's page.

So even though that apk carries big words, like "mediatek", it may not necessarily be anything vitally important, or related to hardware and as such I would consider it "bloat".

[AnonymousWP]

What is the stance towards documenting everything for this project? For example, I have a stock flashlight app (and a bunch of other obvious user-oriented apks) that is "Unknown", should I try to provide info for all of them or only for those that potentially raise alarms?

Yes, all pre-installed apps, so not the ones you installed from the Play Store. One of them could be the default flashlight app, yes, as long as you didn't download it yourself.

There's another issue with debloating, that it may give a false impression that you're fully in control.

Who claims you're fully in control when debloating?

[qumuq-til]

Who claims you're fully in control when debloating?

There's no claim but there might be an impression amongst the many. Just a quick note setting the expectations correctly would be nice. It might have been unnecessary to mention if the utility wasn't so easy to use and accessible to a wide range of casual users.

I don't want to open another issue, so here's another suggestion: maybe check for apk signatures and canonical names too. The list correctly mentions that some seemingly stock Android apps are replaced by vendors with their own versions without changing package names. That could be something that uad-ng could put into a separate "forged/hijacked" category. To give you an example this is what I see on my device for com.android.egg (Android S Easter Egg):

Shouldn't be too hard to check for the expected correct signing information.

[AnonymousWP]

If you think the README (or package description) should be changed, please open a pull request.

As for the other 'uniqueness' of packages: that'll require us to calculate hashes for every single package, and still then you'll have the same package names.

[qumuq-til]

I was proposing checking for certificate signatures instead of checksums/hashes, and there are several ways to do that. For example, when you unzip an apk it's possible to run openssl pkcs7 -in ./EasterEgg/META-INF/CERT.RSA -inform DER -print_certs -noout Which in my specific case gets you subject=C = CN, ST = Shanghai, L = Xuhui, O = greatflag, OU = SW, CN = dazhi, emailAddress = dazhi@dazhi.sh.cn issuer=C = CN, ST = Shanghai, L = Xuhui, O = greatflag, OU = SW, CN = dazhi, emailAddress = dazhi@dazhi.sh.cn

Instead of the expected subject=C = US, ST = California, L = Mountain View, O = Google Inc., OU = Android, CN = Android issuer=C = US, ST = California, L = Mountain View, O = Google Inc., OU = Android, CN = Android

It's the 'expected' output that I propose be added as a signature check in the list for every stock Android app. In uad-ng instead of a separate category an even better idea might be to prefix the package name with an exclamation symbol signifying that an application had been tampered with.

What I'm not sure about is how to extract that information with as little effort as possible, but I know of two tools, apksigner and keytool that could be bundled with uad-ng. Or maybe there exists a simple way to look inside an apk because all we really need is the CERT.RSA file and the openssl which comes preinstalled on macos and Linux.

[AnonymousWP]

As for certificates, please create an issue. If you want to have the description changed, please open a PR.