yashsingh1/xdaforums huggingface dataset:
[Android Q&A, Help & Troubleshooting] rocker00:
What's going on here?! i didn't read all the posts but everything is wrong, gapps version, android version, the ROM is old or not!! YOU CAN'T FIX THIS ISSUE UNLESS YOU REMOVE GOOGLE SPOOFING OR MAKE IT USELESS AS I DID, check the attachment it will explains everything, some ROMs require one more step to be able to boot the ROM by deleting the following:

system/framework/arm & arm64/boot-framework.art, boot-framework.oat and boot-framework.vdex (Deodexing framework.jar)

Also some ROMs have another smali codes in a different xml which i don't even remember the name of it, it's better to use notepad++ to search for everything related then use MT Manager not apktool, it gives a corrupted framework.jar, at least for me.

I actually have nothing to say to the developers, an issue like that which makes the ROM unusable and not a single action until now?! what about the average users who can't do that? do you really think that modifying the framework + the extra steps is an easy job for everyone?

Remove the spoofing or make it useless (Google stuff), otherwise don't waste your time.

Using One UI right now so i don't give a **** about this anymore.

x0xb0x Check the extra step above it should helps out.
[Android Q&A, Help & Troubleshooting] mmortal03:
I look forward to your results with the zipped PixelPropsUtils.smali file he included. I believe you are referring to this post of his?: https://xdaforums.com/t/temp-fix-ro...le-play-services.4406617/page-5#post-87173867

Well, with all due respect, you probably CAN fix this issue without removing the spoofing, but we just don't know enough details here to be able to do it, as we don't even know *why* the spoofing presents with this bug. And, like you said, most people aren't going to know how to do what you did. Maybe x0xb0x will finally succeed, though.
[Android Q&A, Help & Troubleshooting] rocker00:
With all due respect too, you CAN'T 100% fix this issue without modifying, fixing or removing the spoofing, and regarding why the spoofing is causing this bug, it's simply because Google don't want the none pixel users to be able to use pixel specific features, so they (created) this behavior to make you suffer as many users now then you finally decide to rollback to the stock ROM or find another ROM without this behavior, about how this bug is happens, since the gms is spoofed as you are a pixel user, the system is trying to download pixel ota update but it fails (which is awesome, otherwise a hard brick), in that past this bug wasn't exists but now Google has patched something to do that, as the safetynet wasn't an issue before but now it is, because of Google also, they are controlling everything, and more on the way, you have my word.

All the fixes I've seen have failed to 100% fix this issue, patching hosts causes many issues even with none Google apps, the cmd line completely breaks sync function, only spoofing gms.unstable was also useless and the issue just came back after less than a month....did i miss any other fix? also, if this bug is fixable without removing of fixing the spoofing, why the developers didn't fix it until now?!

Having a stable ROM is much more important than this spoofing, it's simple logic!
[Android Q&A, Help & Troubleshooting] mmortal03:
I agree that this is broadly the right explanation, but it isn't specific enough to describe what's happening at the level of the code. In particular, we know that the system update errors only start happening after a number of months after a ROM has been built. That's why I think there must be a date variable that the Google system update code is checking (possibly the security patch date).

In no longer supported ROMs, we could potentially just patch that date with the current date or some future date, such that the system update errors wouldn't start for longer. This should be a simple workaround without side effects. But we just don't know which date to patch.

I believe it's because, in practice, it mostly affects ROMs that are no longer supported.

Currently, some supported ROMs could still have the spoofing, but, by definition, they are continuing to get regular builds or security updates, so they are avoiding the bug this way. It's only the unsupported ROMs which, by definition, don't have updates for many months if at all, where we practically have the problem, without devs around any longer to properly fix it, or even release updated builds.

Yes, no disagreement there!
[Android Q&A, Help & Troubleshooting] amn1987:
I had experienced issues with Sync in case of Google apps after applying the fix only in the first few months. Thereafter no issue. Regular builds are available in case of all my devices barring one (which fortunately is on an older Havoc build which didn't include the Pixel Spoof ) but I usually update only every few months or so.
[Android Q&A, Help & Troubleshooting] rocker00:
This is incorrect, before i move to One UI, i remember i was on an up to date ROM, (android 13 with an up to date security patch) and the issue is happened, i complained to the lead dev and many users followed me but he ignored, then i decided to think out of the box and i 100% succeeded, trust me buddy, it happens on the old & up to date ROMs as well, that's what i experienced on A11-A13 after Google has decided to do that.

Off topic, forgot to mentioning a very important thing, and it doesn't matter if there's a spoofing or not, if you are using any ad blocker app and you're using Youtube music app this will cause similar bugs that spoofing causes, overheating, battery drain and bad performance, you can see a flood on the logcat similar to the spoofing flood and it won't stop until you force stop Youtube music, and it's not only when you start Youtube music, once you trigger any audio apps this will happens if Youtube music is installed, just mentioning this to avoid any confusion between this bug and the spoofing since they are very similar.

As you can see, again, it's Google!
[Android Q&A, Help & Troubleshooting] mmortal03:
There may be different iterations of this bug, depending on the ROM or phone, because over in Moto G5 Plus (potter) threads (crdroid and LOS), we are definitely seeing a delay of a few months before the error messages and battery drain starts.

Yeah, I recall there being a battery drain bug related to what we're talking about here that was even impacting stock Android, maybe on Pixels, but I can't remember. I'll see if I can find it.
[Android Q&A, Help & Troubleshooting] cjdijk:
@rocker00:

I want to get rid of Pixel Spoofing, I don't need the unlimited Google Photo space, just don't want battery draining, but want to keep Google services, using for expample calendar and contacts from my Google account. Can I just flash spoofing.zip, booting to twrp recovery?

@mmortal03:

I did send gothicVI a personal message, that I am still using my Moto G5 Plus (potter) as my main smartphone, using his version of lineage-18.1 and he answered: "Thanks for the feedback. As long as the lineageos 18.1 branch receives security patches I'll try to build monthly."

@gothicVI:

Installing NikGapps-basic-arm64-11-20230716-signed didn't help, I still did have battery draining (starting this month). Thanks for the new update lineage-18.1-20230911-UNOFFICIAL-potter_security-patch-date_2023-09-05.zip I have installed it an hour ago, using twrp recovery, only using install zip, without formatting of wiping. So far everyting works. Thanks again!

lineage-18.1-20230911-UNOFFICIAL-potter_security-patch-date_2023-09-05.zip | by gothicVI for Potter

Download GApps, Roms, Kernels, Themes, Firmware, and more. Free file hosting for all Android developers.

androidfilehost.com

Unfortunately something went wrong. Battery drain is higher then ever before. 15% in one hour! I have decided to perform a whole fresh install including formatting and wiping. To be continued.
[Android Q&A, Help & Troubleshooting] mmortal03:
That won't work.
[Android Q&A, Help & Troubleshooting] amn1987:
All this experimentation might kill the battery. I guess the original battery would have been permanently OOS long back.
[Android Q&A, Help & Troubleshooting] cjdijk:
Yes that's it, I guess I've switched GApps using just install zip too much. After a fresh clean install using the old/official MindTheGApps with the newest Lineage it all works fine. (Before that I've tried a fresh/clean install with NikGapps, but thats not working for me. I wasn't able to restore my Google backup with that.) By the way, also I couldn't restore the backup creeated by SwiftBackup. I had created a full backup with that on my sd-card, but without data, wasn't able to get my phone rooted. Do I need a payed account or something?
[Android Q&A, Help & Troubleshooting] amn1987:
In case of NikGApps a separate addon is required for stuff like Google backup. I never bothered with it.

When you say "without data" do you mean mobile data? Swift Backup requires logging into Google account before the backup can be restored. Internet access in any form is necessary obviously. Lastly without root Swift Backup cannot restore app data. Only apks can be restored using Shizuku which requires ADB permissions.
[Android Q&A, Help & Troubleshooting] cjdijk:
With backuping data, I mean I don't have to configure all apps one by one. Is that the data partition? Has nothing to do with mobile data. I think I need to figure out how to get my smarphone rooted to be able to backup data (partition). I'm sure I have created a apps backup on my sd-card using Swift Backup. But strange thing was, when I tried to resore the backup (apps only) using Swiftbackup, it couldn't restore it. I guess I'm going to stick with the old MindTheGApps. By the way, battery draining is gone. Used only 5% during 8 hours of sleep. So i'm happy for at least one month.
[Android Q&A, Help & Troubleshooting] x0xb0x:
Thanks for responding!

I 'll try you approach, especially deodexing boot-frameworl.vdex and removing the oat/art files. I see from your smali that you neutered the spoof vs ripping it. Nice and efficient approach!

I was initially trying a complete PixelPropsUtils smali removal, but will first try to decompile+recompile unmodified framework.jar using your deodex hint and see if it boots.

Subsequently if the unmodified+rebuilt framework boots then I (may/might) proceed and remove the spoofing.
[Android Q&A, Help & Troubleshooting] cjdijk:
It looks like battery usage is quite high, despite my rom isn't one month old. Can someone help me, tell me how to get rid of the Pixel Spoofing. The full guide with all steps needed for dummies. Beste thing would be a twrp flashable zip file for my Moto G5 Plus, but don't know if that's possible, and if it would work for other rom's like DotOS for potter. I seriously consider going back to stock Android 8.1, or even buy a new Moto G84 5G. But I would prefer keep using my Moto G5 Plus with Android 11, but without the battery drain issue. And also keeping my Google account/services. I still think it's a bit strange that rom developers aren't all working on this mayor problem. There is no way I ever want to switch to any custom rom again. This shoud be the only thing developers would spend their time on.
[Android Q&A, Help & Troubleshooting] mmortal03:
That would definitely be nice for someone to do this. That's the whole problem here. No one with enough knowledge is wanting to expend the effort.
[Android Q&A, Help & Troubleshooting] cjdijk:
I can't find system/framework.jar on the internal storage of my phone? I guess I need to get my phone rooted first, but still don't know how to do that. So I have to figure out that first, as soon I have time.

Also a question in advance. How do I modify a jar file? I have searched that on Google, I guess I can extract it using 7Zip, but how do I write the modified jar file? Or is a jar file compatible with zip, rar or 7z?
[Android Q&A, Help & Troubleshooting] rocker00:
x0xb0x Typically like i expected, once i read your post i was sure that you gonna make it, awesome :)​

Safetynet, that spoofing is also controlling the safetynet, so, once you modify or remove it then you have to adapt the new configuration, simply, pickup a stock fingerprint with the same security patch level that comes with it and modify build.prop and you should pass the safetynet, and ignore the device is showing an old security patch, just a number, i already experienced your situation when i removed or even modified the spoofing, also this module is mandatory (ofc) https://github.com/Displax/safetynet-fix/releases, and for the banking apps or any apps that detect the root use shamiko module and put the app/s in the deny list on magisk and you're good to go.

At the first time i did exactly like you, complete removing of the spoofing but i felt like why should i loose the spoofing for the games then i decided to only modify the spoofing.

Even after you clarified everything (what a patience!!!!) i believe that not everyone will be able to do that, it's a real mess and not everyone will be willing to go through this mess, for example, not everyone is rooted then you have to make a recovery patch as an alternative, bla bla bla, this mess should ends by the developers, anyways, glad you made it and thanks for confirming everything i just said!
[Android Q&A, Help & Troubleshooting] x0xb0x:
You are welcome to try but on a scale of technical difficulty from 0-10 ... I easily think this one was an 11.

I outlined the framework related steps for the very experienced modding members.

If I billed this in work hours for a client I could maybe buy quite some new flagship devices.

I did it because @rocker00 led the way with important hints, and because I got very frustrated with the whole situation and people pretending it's ok and ignoring it.

Also the whole "change rom constantly" trend is not feasible for a daily device.

Removing spoof is the only way to fix things and should have been done by rom developers from the start. So many wonderful rom builds out there are waiting to turn your device into a toaster.

LineageOS got it right. NO SPOOFING and adios.

Oh did I mention that the same steps I described do not work on my second phone with a slightly different crDroid 7.x version?

Why? Because in this rom ALL the build.prop files are also spoofed and not just the framework.jar... So I have to amend the guide once I fully fix this as well.

I respect immensely the work done by rom developers but cannot understand why they included such a "feature".

Easily one of the most unpleasant rom modding tasks I ever performed.
[Android Q&A, Help & Troubleshooting] rocker00:
That's exactly the point!, that's why i no longer share any mods or even fixes since the majority are always clapping for everything.

Ist time i experienced this behavior and after i identified the cause with the evidence, i complained to the lead DEV with the attached log and explained everything and he just ignored! and guess what? some "intelligent" users attacked me!! it's like how dare you criticize the ROM? one of those "intelligent" was "a maintainer", he said all these issues you're referring to are device side issues...probably a kernel issue, so, don't complain about the ROM and complain to your maintainer!! i repeat, a maintainer...Lol!

Everyone participated in this thread, wish you luck, unfortunately, can't help more.

For the always clapping users who don't even dare to open their mouths, ENJOY!
[Android Q&A, Help & Troubleshooting] cjdijk:
I guess I'm going to buy a new smartphone (Moto G84 5G) at black friday on november 24 this year. Let's hope I'll get updates 2 more month's by gothicVI. By then it's price will be about the same as I paid for my Moto G5 Plus (240 euro). At this moment it already has dropped to 278 euro. And I wil never ever going to install any custom rom again. Also after it's stuck with android 14, not getting an stock update to Android 15. Becouse after it's custom rom isn't supported anymore, it becomes unusable becouse of the battery drain. And it's too difficult for people like me to fix it. I remember it was difficult for me to go from stock to custum. Hours of watching guides on youtube during Corona. When I had succes, I created a full guide for others (Dutch language). https://gathering.tweakers.net/forum/list_message/66796802#66796802 I still think, a modified GApps would solve this issue. I know installing a custom rom without GApps works fine. No battery drain at all. Have tried that. But that's not going to work for me, I need Google Playservices/Google Account. I can install apk's using ADB. Can access my calendar/contacts using Firefox, going to calendar.google.com and contacts.google.com But that's not as easy as just using GApps. Thanks you all anyway.
[Android Q&A, Help & Troubleshooting] amn1987:
If you don't use paid apps then you can use microG. No such issue will be encountered. Previously with the help of a modded Play Store I could use paid apps as well but about a year back when I last tried many such apps (but not all) like Tasker, Franco Kernel Manager kept complaining about licensing issues.
[Android Q&A, Help & Troubleshooting] x0xb0x:
@rocker00 News from the front: I managed to also despoof my crdroid 7.22 mi9.

This was a true nightmare. Apart from framework.jar I also had to despoof all build.prop files.

And then ... upon rebooting I discovered by running "getprop" on termux that vital properties were still spoofed. The culprit was in native boot code, investigation showed there many github repos where rom maintainers force native init process to set custom ro.* properties. 😭

I despoofed those with the following script placed in Magisk post-fs-data.d folder as described by official Magisk docs. They instruct to not use setprop but resetprop -n:

resetprop -n ro.build.fingerprint "Xiaomi/cepheus/cepheus:11/RKQ1.200826.002/V12.5.1.0.RFAMIXM:user/release-keys"
resetprop -n ro.bootimage.build.fingerprint "Xiaomi/cepheus/cepheus:11/RKQ1.200826.002/V12.5.1.0.RFAMIXM:user/release-keys"
resetprop -n ro.odm.build.fingerprint "Xiaomi/cepheus/cepheus:11/RKQ1.200826.002/V12.5.1.0.RFAMIXM:user/release-keys"
resetprop -n ro.product.build.fingerprint "Xiaomi/cepheus/cepheus:11/RKQ1.200826.002/V12.5.1.0.RFAMIXM:user/release-keys"
resetprop -n ro.system.build.fingerprint "Xiaomi/cepheus/cepheus:11/RKQ1.200826.002/V12.5.1.0.RFAMIXM:user/release-keys"
resetprop -n ro.system_ext.build.fingerprint "Xiaomi/cepheus/cepheus:11/RKQ1.200826.002/V12.5.1.0.RFAMIXM:user/release-keys"
resetprop -n ro.vendor.build.fingerprint "Xiaomi/cepheus/cepheus:11/RKQ1.200826.002/V12.5.1.0.RFAMIXM:user/release-keys"
resetprop -n ro.build.description "cepheus-userdebug 11 RKQ1.200826.002 151725 release-keys"

After this step everything is unspoofed and my account security settings recognize the phone as Xiaomi mi 9.

Google 2fa prompts naming your phone may still be stuck to your old spoofed device name such as "Pixel 5".

You can change this leftover string by renaming your previously spoofed device in "Find my device" web application. What I mean here is that even though Google account active session says Android device "Xiaomi mi9" (thank God) the 2fa prompts might have the Pixel name leftover.

I will probably put all of this work along with descriptions and my custom despoof scripts on Github.

Now I need to see if this work can translate to crdroid 9.x (A13). Time will tell.

I should probably build the A13 roms myself and remove all the spoofing in source code. The device repos for most A13 roms are still online and haven't disappeared as usually is the case with outdated Android versions.
[Android Q&A, Help & Troubleshooting] rocker00:
Yeah, sometimes they also spoof the SAR file (system/bin/init), they include the fingerprint props, the device code name and more, in this case only modifying the framework and the props isn't enough, i always use "a free" init that has no fingerprint, no device code, nothing related at all, and it always boots, i don't remember that i wasn't able to boot any ROM with this free init...i can call it " A GSI" init, i totally forgot about that, my bad.

Make sure your build.prop contains the following line, and if it's not there add it:

ro.build.fingerprint=xxxx

don't rely on ro.system.build.fingerprint=xxxx

I attached the init that i was using for both android version you mentioned, just in case, please back this file up before trying, now you can remove the modifications you have done via magisk and give a try, also there's no need now to build the ROMs from the scratch since the spoofing has completely removed.
[Android Q&A, Help & Troubleshooting] x0xb0x:
This is awesome matey. The ro.build.fingerprint you suggested was already there in my system/build.prop BUT the rom's init was spoofing it. Hence the need for a Magisk post-fs script.

But when I try the GSI init files I'll update you, this is a very nice approach you suggested. Just FYI (and anyone interested) I heavily modified all my crDroid-7.22-mi9 propfiles (their spoofed attributes) with the ones from latest miui A11.

Also some important info I totally forgot that is now working in both my devices:

To zipalign the MT produced framework.jar ONLY the following process will produce a booting & correctly zipaligned jar:

unzip framework.jar -d framework_files
rm framework.jar
jar -c -v -0 -f framework_tmp.jar -C framework_files .
zipalign -f -v 4 framework_tmp.jar framework.jar
rm framework_tmp.jar

What I noticed nowadays is how apktool and all suggested combinations of command-line switches together with manual help from smali/baksmali, fail to automatically identify the correct SDK, hidden API calls (and maybe other stuff)

They always produced a non booting framework.jar (not experienced this in the past before A8). There are some Github issues mentioning this but I can understand how hard it is for the developers to troubleshoot boot issues.

But MT manager gets it right everytime. I didn't even get a prompt to manually select the SDK version used, it figured everything out itself correctly along with managing hidden api calls and dex rebuild.
[Android Q&A, Help & Troubleshooting] x0xb0x:
Tried your GSI (Generic System Image) init for A11. Unfortunately it just throws me back to TWRP. Reverted to original init and my Magisk post-fs script approach.

Thanks a lot though, it is a struggle to find such info. When I try your A13 init attachment I will also report on that as well.
[Android Q&A, Help & Troubleshooting] rocker00:
Weird! i always use this way and it boots fine, if you want to experiment you can try with permissive selinux or maybe another kernel, i totally understand that this file is critical but it always boots even when i was porting ROMs like OOS, but the good thing is that you have an alternative way to fix this part.
[Android Q&A, Help & Troubleshooting] X3User:
I can confirm that there is no issue and I've been using it for a month now (the funny thing is that unlimited gphotos still works). And also I can use FKM (maybe because I downloaded it from telegram). The playstore I'm using is the one patched by Nanolx
[Android Q&A, Help & Troubleshooting] amn1987:
Yes modded apps don't do licensing checks and stuff of course. I was successful in using paid apps with microG back in 2020 but thereafter I have tried microG (various implementations) a few times but licensing always fails for whatever reason in case of a select few apps which are must haves. I am forced to use GApps (NikGApps Core) in the 2GB RAM variant of Redmi 3s whereas microG would have been a way better fit.
[Android Q&A, Help & Troubleshooting] luxsam5:
I use AppManager(by MuntashirAkon) to survive play services update
[Android Q&A, Help & Troubleshooting] Mendochief:
I use 3C All-in-One Toolbox to disable unnecessary Google Play Services and Naptime to doze the remaining services, my battery stays the same percentage for hours. You're welcome.
[Android Q&A, Help & Troubleshooting] endale ni:
cpu
[Android Q&A, Help & Troubleshooting] chaoscreater:
I use AppManager too but can you elaborate on what you meant please?