Couldn't Install on Moto XT2215-4 with Android 12

[whitedavidp]

Wish it worked on this device. Not sure I get why not. But... Thanks

magisk_install_log_2024-08-28T17.02.57.log
NFCScreenOff-v2.1.2.zip

[whitedavidp]

And here are the other two files:
NFCScreenOff_upload_this1.zip
NFCScreenOff_upload_this2.zip

[whitedavidp]

Hi. While all of this is above my paygrade really, I looked at the customize.sh file. I note this line:
NFC_APPS='NfcNci NQNfcNci NxpNfcNci Nfc_st'

This appears to be the names of specific files to be manipulated somehow. I looked in /system/system_ext/app and I see only two of these:
NQNfcNci
Nfc_st

I also see a number of others with Nfc in their names:
NfcNciNxp
NfcSec
NfcSetup
NfcSetup_Sec
NfcSetup_st

I cannot help but note that the file I have 'NfcNciNxp' is very close to the one mentioned in the script 'NxpNfcNci' and I wonder if this is a reason why this is not working on my device?

Also, it appears that if more than one file matches (in my case: 1st is NQNfcNci, 2nd would be Nfc_st), only the first one is modded. I can see this in the install log attached above. I don't know what is used to determine why the "MODDING FAILED" but I cannot help but wonder if the modding might NOT fail if the file Nfc_st was used instead?

If so, I have no idea how I might deal with this change. Any suggestions? Thanks

[whitedavidp]

I decided to try editing the customize and service shell scripts in v 2.1.2 so they would find Nfc_st before NQNfcNci and see if I get any further. I did the simple edits and re-zipped the entire contents. I then tried to install once again. Still get MODDING FAILED. Rats! Here are the files:
magisk_install_log_2024-08-30T14.59.58.log
NFCScreenOff.zip
NFCScreenOff_upload_this1.zip
NFCScreenOff_upload_this2.zip

I wish I knew what the cause of the MODDING FAILED is. For example does the modding process search for specific items in the smali and, if not found, fail? Thanks!

[whitedavidp]

And I tried again forcing the scripts to find NfcNciNxp instead of NxpNfcNci and that didn't work either. I won't bother posting that info as it is clear to me that I am just flogging around - knowing nothing about what is really going on here.

[whitedavidp]

So I installed the ApkStudio app on my PC and had it process the file NfcNciNxp.apk from my device. I chose this because the file NfcNci.apk described in the patcher does not exist on my device and NfcNciNxp.apk is the closest in name.

After ApkStudio did its thing, I looked at the files mentioned:

com/android/nfc/NfcService.smali
com/android/nfc/ScreenStateHelper.smali

and compared them to the diffs shown here.

Here are the files - with .txt added to the name to get them "supported" for inclusion.

NfcService.smali.txt
ScreenStateHelper.smali.txt

In NfcService.smali, I find:

a) NFC_POLLING_MODE is there and defined as 0x8 as expected. But it is on line 220 in the file rather than 92 as shown in the diffs.
b) I find the SCREEN_OFF at line 1644 rather than on line 911. And more importantly, I find the line to be different than shown:
const-string v6, "android.intent.action.SCREEN_OFF"
instead of
const-string v0, "android.intent.action.SCREEN_OFF"
c) Similar to (b), I find SCREEN_ON at line 1652 rather than at 916. But other than this, it seems identical.
d) Similar to (c), I find USER_PRESENT at line 1657 rather than at 921. But again, it seems otherwise identical.
e) Similar to (c) and (d), I find USER_SWITCHED at line 1662 rather than at 926. Again, it seems identical otherwise.

However, things look quite different in ScreenStateHelper.smali. I do see some lines that look like what are shown in the diffs at lines 81-99. But they are in different locations and have different surrounding lines.

Any suggestions on how to proceed?

[whitedavidp]

I went back to the original to try again...

And I'll be dipped!

I made modification to the customize and service scripts to force them both to recognize and use the NfcNciNxp.apk. I re-zipped and installed into Magisk letting it do its thing, and rebooted.

Once I did, I am now able to trigger NFC with screen off or AOD (Peek Screen) on. And, oh joy!, no more sound - just vibration.

Thank you, thank you, thank you.

[Jon8RFC]

I'm sorry I just now saw this.

That's awesome that you got it working on your own--nice going!
Thank you for all of the appropriate files, too.

During the Android 13 lifecycle, the necessary parts to change were moved. As a result, the patcher searches for what to modify, which you mentioned. It also uses a different apktool, depending on which Android version it's working with. There's a flag (--aapt1) to have the newer apktool function with Android 13 and older, but it didn't work when I tried it. Instead, the patcher also has an older apktool and it determines which one to use.

It shouldn't play a role on the server's end since it's not 13/14, but when I google your phone's build S1SDS32.56-81-16, it shows as Android 12 as you mentioned. However, the patcher is reporting it as Android 11 under API 30, which it pulls from build.prop files. Do you happen to have anything modifying various .prop files to change their android or API versions? It may be that the developers did something funky, causing the discrepancy.

I have some future changes planned to search for NFC apk files more broadly, but this type of scenario is a concern--confusion on which file to patch, if there are file vestiges, if Android eventually splits things, or if the build.prop files are incorrect. Referencing the Android version is required for determining which apktool to use, but that shouldn't play a role in Android 11 versus 12.

I'm perplexed and will need to take a look at where it breaks along the searching/patching to see what I need to fix and/or add.

I may ask you to test another patcher after I look around, if you don't mind.
Thanks again for the files and all of the info!

[Jon8RFC]

NfcNciNxp

I forgot that part as I was looking through the logs and typing my response, above.
It's easy to add it in, but you also have other matching (possibly vestigial) files, unfortunately.

My new code has been a work-in-progress since May or June, and it would do wildcard NFC file searching for unknown file names like NfcNciNxp, but I haven't decided on a way to properly go about determining which files to attempt patching. I had an idea once I realized just how many various NFC folders and files my Pixel had, but I've since forgotten that idea.

It'd be a nuisance for the user to wait as it attempts patching one at a time until one works, especially if they have slow upload speeds. Having to upload multiple apk files at once (which would speed up server-side operation) might be too long of a wait if it takes many minutes, without any periodic Magisk feedback of "it's still uploading and waiting", which I can't do.

I do have a new server I need to move the patcher to, because patching is a slow process, so that part can be helped. Uploading 3 or more candidate files would be a nuisance for the user, I would think.

If you have any ideas, please let me know. I really would like to remember my idea from a few months ago.

[Jon8RFC]

You said it's "above my paygrade", but no, it's really not!
You figured out a lot, just like I did, and faster than I did. I was clueless in the beginning, but poking around and searches helped a lot.

https://github.com/Jon8RFC/nfcscreenoffpatcher

That's the server-side patcher, if you're curious.

I think my idea concerned nearby files/folders. I was going to ignore candidate NFC apks if the NFC folder didn't also contain certain files/folders.

[whitedavidp]

It shouldn't play a role on the server's end since it's not 13/14, but when I google your phone's build S1SDS32.56-81-16, it shows as Android 12 as you mentioned. However, the patcher is reporting it as Android 11 under API 30, which it pulls from build.prop files. Do you happen to have anything modifying various .prop files to change their android or API versions? It may be that the developers did something funky, causing the discrepancy.

I have not installed anything that should be messing with the build.prop file. Here it is (with .txt added to make the file "compatible"):
build.prop.txt

But having said this, when I first got the phone, I had some interactions with these folks - trying to get a working TWRP - didn't work out but they have a great idea. Anyhow, during that interaction, they too had confusion over the true Android version.

The phone reports as A12 in the about device settings page. The specs I looked at indicate it was released with A12. The aida64 app shows A12 as well. And from what little I have read in the build.props file, it says A12 too. And during rooting, I used this file to get the boot image for Magisk. The name, XT2215-4_MILANF_RETUS_12_S1SDS32.56-81-16, certainly implies A12 as well.

So perhaps some screw up at Moto? Or something on the cusp 11/12?

The fact that the phone has an NFC settings page almost exactly like the one shown here - with a switch supposedly to disable required unlocking for NFC - that seems to do nothing at all, to me is an indicator that the firmware builders did not dot all the "i's" and cross all the "t's".

[whitedavidp]

I have some future changes planned to search for NFC apk files more broadly, but this type of scenario is a concern--confusion on which file to patch, if there are file vestiges, if Android eventually splits things, or if the build.prop files are incorrect.

Yes, I am not sure why there are so many NFC-related files on my device. And it is confusing. I theorized that the strange but similar app naming might indicate what to use. But I only became more sure what app to use after I ran it through ApkStudio and looked at the files mentioned in the modding details section.

One thing I do note it that the customize and service shell scripts both seem to always use the last file in the list if multiple qualifying files are found. Same was true of the original. I had to edit the scripts to put my device's app at the start and then put break statements into the for loops to get what I wanted. I am not sure if it is possible to prompt the user during the Magisk install. But that might make it less difficult for others. (1) Find all the matching apk names and then (2) prompt the user which to mod/use.

[whitedavidp]

My new code has been a work-in-progress since May or June, and it would do wildcard NFC file searching for unknown file names like NfcNciNxp, but I haven't decided on a way to properly go about determining which files to attempt patching. I had an idea once I realized just how many various NFC folders and files my Pixel had, but I've since forgotten that idea.

It'd be a nuisance for the user to wait as it attempts patching one at a time until one works, especially if they have slow upload speeds. Having to upload multiple apk files at once (which would speed up server-side operation) might be too long of a wait if it takes many minutes, without any periodic Magisk feedback of "it's still uploading and waiting", which I can't do.

I do have a new server I need to move the patcher to, because patching is a slow process, so that part can be helped. Uploading 3 or more candidate files would be a nuisance for the user, I would think.

If you have any ideas, please let me know. I really would like to remember my idea from a few months ago.

I used to have a root app on Play Store called Cookie Manager for System Web View (Google since removed it even though it was fine because I did not "update it") that had to search for a specific database file somewhere in an app's internal files under /data/data. I ended up having to shell out and grep files - sometime multiple times - to find the exact right one (and even then it was not 100% correct).

The idea of having the patching server look for the target smali code in amongst multiple possible patching candidates does seem awkward and slow. But if there are multiple candidates and you prompt the user which to try and the user can try them one at a time to see which - if any - produces a working result, that might be ok. For the user, this is (hopefully) a one-time deal per device. And the result is so desirable/needed that I think most would work at it if the process were easy enough.

The one thing that really confused me about your implementation (and did not happen on the original) is that it tells me MODDING FAILED. But there is no information about why/how this result was reached. I was successful using the original fork, not this one. So I cannot help but wonder why that is and why the modding succeeded there and not here.