• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!

[Discussion] Google Pay Magisk Discussion Thread

Search This thread

Fry-kun

Senior Member
Sep 19, 2012
121
17
Google Pixel 4 XL
I expanded the trigger SQL a bit. The app that checks the attestation state (GMS toolbox by @Freshek) is looking at a different table in a different db (Wallets in android_pay) as opposed to the method by @BostonDan which is looking at main in dg.db.
[...]

Applied this to my phone, but Pay still doesn't let me set up a card to use in store. Is there a step I'm missing other than applying the sql commands?
I've verified with sqlite3 that the fields are updated as per script.
 

hanneshoch3

Member
Mar 22, 2011
23
9
Try setting it read-only, that's the only way it works for me as well. Neither the script nor manual changes do the trick without it being read-only. Make sure to have set the fields to 0 before you make it r/o. However, sometimes the terminal still declines the card after some time, even though gpay says it worked fine. Then I have to remove gms folder and do the same procedure again so I can setup PayPal again.
 

jcmm11

Recognized Contributor
Feb 10, 2012
3,587
3,602
Google Pixel 4a 5G
Applied this to my phone, but Pay still doesn't let me set up a card to use in store. Is there a step I'm missing other than applying the sql commands?
I've verified with sqlite3 that the fields are updated as per script.
Some feedback seems to say that setting dg.db RO allowed you to add cards. Feedback also states you can change it back to RW after adding the cards
 

Xx-Ness-xX

Senior Member
Nov 15, 2010
130
27
Chicago
In your script:

CREATE TRIGGER IF NOT EXISTS fails_attestation_update AFTER UPDATE OF fails_attestation
ON Wallets WHEN (NEW.fails_attestation <> 0)

isn't the bold font supposed to be OLD?

P.S. I don't know much about sql programming but I am just trying to make sense out of it

Thanks,

I expanded the trigger SQL a bit. The app that checks the attestation state (GMS toolbox by @Freshek) is looking at a different table in a different db (Wallets in android_pay) as opposed to the method by @BostonDan which is looking at main in dg.db.

So I created triggers for both tables. There's 2 sql files in the attached zip file. One will set any non-zero attestation values to zero and also create both insert and update triggers for both tables.
The second file drops (removes) the triggers from both tables, but doesn't change any values.

This solution doesn't need any permission changes and should, in theory, be good for any updates going forward - unless they change the table structure. If it works it's apply and forget.

I strongly recommend using the Magisk Mod for SQLite. To apply these files feed them into the sqlite3 binary. Assuming you have them in the root of sdcard, and using attest.sql as the example just run, as root
Code:
sqlite3 < /sdcard/attest.sql
If you've already applied the previous files I posted these won't hurt anything, you can apply these over those with no problems. Contents of attest.sql
Code:
.open /data/data/com.google.android.gms/databases/dg.db
UPDATE main SET c='0' WHERE a LIKE '%attest%';

CREATE TRIGGER IF NOT EXISTS attestation_insert AFTER INSERT 
ON main WHEN (NEW.a LIKE '%attest%' AND NEW.c <> 0)
BEGIN
UPDATE main SET c = 0 WHERE ROWID = NEW.ROWID;
END;

CREATE TRIGGER IF NOT EXISTS attestation_update AFTER UPDATE OF c 
ON main WHEN (OLD.a LIKE '%attest%' AND NEW.c <> 0)
BEGIN
UPDATE main SET c = 0 WHERE ROWID = OLD.ROWID;
END;
.schema main

.open /data/data/com.google.android.gms/databases/android_pay
UPDATE Wallets SET fails_attestation=0 WHERE fails_attestation <> 0;

CREATE TRIGGER IF NOT EXISTS fails_attestation_insert AFTER INSERT 
ON Wallets WHEN (NEW.fails_attestation <> 0)
BEGIN
UPDATE Wallets SET fails_attestation = 0 WHERE ROWID = NEW.ROWID;
END;

CREATE TRIGGER IF NOT EXISTS fails_attestation_update AFTER UPDATE OF fails_attestation 
ON Wallets WHEN (NEW.fails_attestation <> 0)
BEGIN
UPDATE Wallets SET fails_attestation = 0 WHERE ROWID = OLD.ROWID;
END;
.schema Wallets
.quit
Contents of drop_attest.sql
Code:
.open /data/data/com.google.android.gms/databases/dg.db
DROP TRIGGER IF EXISTS attestation_insert;

DROP TRIGGER IF EXISTS attestation_update;
.schema main

.open /data/data/com.google.android.gms/databases/android_pay
DROP TRIGGER IF EXISTS fails_attestation_insert;

DROP TRIGGER IF EXISTS fails_attestation_update;
.schema Wallets
.quit
 

irony_delerium

Senior Member
Jan 13, 2013
305
206
Portland, OR
Samsung Galaxy Z Flip
In your script:

CREATE TRIGGER IF NOT EXISTS fails_attestation_update AFTER UPDATE OF fails_attestation
ON Wallets WHEN (NEW.fails_attestation <> 0)

isn't the bold font supposed to be OLD?

Nope. It's checking the updated row (alias NEW), not the original row (which would be OLD). If GMS sets Wallets.fails_attestation to anything non-zero, the trigger executes after the update statement is finished.
 

Clark789

Senior Member
Sep 15, 2006
407
166
Hamburg
Hi,

yesterday at first with Magisk 19.0 (OP3T, stock OOS 5.0.8) my payment with Google Pay didn't want to work. After i have made an update to Magisk 19.2, it worked without any issues. Just for information...

Regards
Clark
 
  • Like
Reactions: ssceddie

GryphonBR

Senior Member
May 6, 2011
206
65
I used the script method to set the values to 0.
Still don't know which script you're referring to, since there are at least two solutions floating around: one that has a longer SQL script, and AFAIK keeps dg.db R/W, and another that should be somewhat shorter and sets dg.db RO. I use the latter with a Termux script I adapted to allow for a widget creation through Termux:Widget and I've had no issues using GPay - I received an update for the app yesterday but was still able to make a purchase without hiccups last night.
 

Nekromantik

Senior Member
Apr 1, 2010
6,646
863
London
Google Pixel 6 Pro
Still don't know which script you're referring to, since there are at least two solutions floating around: one that has a longer SQL script, and AFAIK keeps dg.db R/W, and another that should be somewhat shorter and sets dg.db RO. I use the latter with a Termux script I adapted to allow for a widget creation through Termux:Widget and I've had no issues using GPay - I received an update for the app yesterday but was still able to make a purchase without hiccups last night.

I used the longer SQLscript that keeps db file RW.
one quoted above by people.
 

GryphonBR

Senior Member
May 6, 2011
206
65
I used the longer SQLscript that keeps db file RW.
one quoted above by people.
That might just be the issue; I haven't used the one keeping dg.db R/W and I have not had any problems since using the alternate script that keeps it RO.

If you want, here's a copy of the script I'm currently using, and as an extra piece of info I have SQlite installed from Termux:
Code:
am force-stop /data/data/com.google.android.apps.walletnfcrel
chmod 777 /data/data/com.google.android.gms/databases/dg.db
/sbin/sqlite3 /data/data/com.google.android.gms/databases/dg.db "update main set c='0' where a like '%attest%';"
chmod 440 /data/data/com.google.android.gms/databases/dg.db
 

Nekromantik

Senior Member
Apr 1, 2010
6,646
863
London
Google Pixel 6 Pro
That might just be the issue; I haven't used the one keeping dg.db R/W and I have not had any problems since using the alternate script that keeps it RO.

If you want, here's a copy of the script I'm currently using, and as an extra piece of info I have SQlite installed from Termux:
Code:
am force-stop /data/data/com.google.android.apps.walletnfcrel
chmod 777 /data/data/com.google.android.gms/databases/dg.db
/sbin/sqlite3 /data/data/com.google.android.gms/databases/dg.db "update main set c='0' where a like '%attest%';"
chmod 440 /data/data/com.google.android.gms/databases/dg.db

will try that thanks
 

dardack

Senior Member
Feb 14, 2011
211
12
I left it as read-only. I was able to add a brand new card to GPay and use the added cards without any concerns - besides, the past couple of times I had the "can't pay in store" message (which were before the SQL patching), the cards were still available on GPay, but I never found a solution before where I could simply keep GPay as was. If it happens again, I'll update this.
.

So just after having a few days to test in store and what not. The attest.sql works great for setting the 0, but doesnt' seem to fix the trigger issue or some other issue. dg.db NEEDS to be Read only for adding cards and for in store payment. It had worked once for me as r/w but went to another store and kept getting error trying to pay, changed to r/o boom worked right away same terminal/store/card. Shrug.
 

dimon222

Senior Member
Sep 27, 2010
215
49
Toronto
romanenko.in
That might just be the issue; I haven't used the one keeping dg.db R/W and I have not had any problems since using the alternate script that keeps it RO.

If you want, here's a copy of the script I'm currently using, and as an extra piece of info I have SQlite installed from Termux:
Code:
am force-stop /data/data/com.google.android.apps.walletnfcrel
chmod 777 /data/data/com.google.android.gms/databases/dg.db
/sbin/sqlite3 /data/data/com.google.android.gms/databases/dg.db "update main set c='0' where a like '%attest%';"
chmod 440 /data/data/com.google.android.gms/databases/dg.db
attest.sql + this = works on my Huawei Mate 20 Pro :good:
 

jsylvia007

Senior Member
Dec 4, 2010
229
48
37
Seekonk
www.jacobsylvia.com
I expanded the trigger SQL a bit. The app that checks the attestation state (GMS toolbox by @Freshek) is looking at a different table in a different db (Wallets in android_pay) as opposed to the method by @BostonDan which is looking at main in dg.db.

So I created triggers for both tables. There's 2 sql files in the attached zip file. One will set any non-zero attestation values to zero and also create both insert and update triggers for both tables.
The second file drops (removes) the triggers from both tables, but doesn't change any values.

This solution doesn't need any permission changes and should, in theory, be good for any updates going forward - unless they change the table structure. If it works it's apply and forget.

I strongly recommend using the Magisk Mod for SQLite. To apply these files feed them into the sqlite3 binary. Assuming you have them in the root of sdcard, and using attest.sql as the example just run, as root
Code:
sqlite3 < /sdcard/attest.sql
If you've already applied the previous files I posted these won't hurt anything, you can apply these over those with no problems. Contents of attest.sql
Code:
.open /data/data/com.google.android.gms/databases/dg.db
UPDATE main SET c='0' WHERE a LIKE '%attest%';

CREATE TRIGGER IF NOT EXISTS attestation_insert AFTER INSERT 
ON main WHEN (NEW.a LIKE '%attest%' AND NEW.c <> 0)
BEGIN
UPDATE main SET c = 0 WHERE ROWID = NEW.ROWID;
END;

CREATE TRIGGER IF NOT EXISTS attestation_update AFTER UPDATE OF c 
ON main WHEN (OLD.a LIKE '%attest%' AND NEW.c <> 0)
BEGIN
UPDATE main SET c = 0 WHERE ROWID = OLD.ROWID;
END;
.schema main

.open /data/data/com.google.android.gms/databases/android_pay
UPDATE Wallets SET fails_attestation=0 WHERE fails_attestation <> 0;

CREATE TRIGGER IF NOT EXISTS fails_attestation_insert AFTER INSERT 
ON Wallets WHEN (NEW.fails_attestation <> 0)
BEGIN
UPDATE Wallets SET fails_attestation = 0 WHERE ROWID = NEW.ROWID;
END;

CREATE TRIGGER IF NOT EXISTS fails_attestation_update AFTER UPDATE OF fails_attestation 
ON Wallets WHEN (NEW.fails_attestation <> 0)
BEGIN
UPDATE Wallets SET fails_attestation = 0 WHERE ROWID = OLD.ROWID;
END;
.schema Wallets
.quit
Contents of drop_attest.sql
Code:
.open /data/data/com.google.android.gms/databases/dg.db
DROP TRIGGER IF EXISTS attestation_insert;

DROP TRIGGER IF EXISTS attestation_update;
.schema main

.open /data/data/com.google.android.gms/databases/android_pay
DROP TRIGGER IF EXISTS fails_attestation_insert;

DROP TRIGGER IF EXISTS fails_attestation_update;
.schema Wallets
.quit

So I ran the attest.sql file from a root terminal. It appears to have applied. I then opened up Google Pay, and tapped "Set up in-store payments" on one of my cards. I was met with: "Couldn't finish setup to pay in stores -- This phone can't be used to pay in stores. This may be because it is rooted or altered in some way."

Is there something else that needs to be done in Magisk? Attestation now shows 0, so that's a plus.
 

dimon222

Senior Member
Sep 27, 2010
215
49
Toronto
romanenko.in
Has anyone thought about turning the above scripts into a Magisk module that monitors one of the lines and runs automatically?
Probably harder since it means monitoring Sqlite 24/7. However, the patch creating triggers can theoretically be incorporated in Magisk module. Not sure if it fits philosophy of Magisk tho, since its mainly dealing with non-modifying of such data.
So I ran the attest.sql file from a root terminal. It appears to have applied. I then opened up Google Pay, and tapped "Set up in-store payments" on one of my cards. I was met with: "Couldn't finish setup to pay in stores -- This phone can't be used to pay in stores. This may be because it is rooted or altered in some way."

Is there something else that needs to be done in Magisk? Attestation now shows 0, so that's a plus.
Check my post couple of messages up, chmods are required as well.
 

jsylvia007

Senior Member
Dec 4, 2010
229
48
37
Seekonk
www.jacobsylvia.com
Probably harder since it means monitoring Sqlite 24/7. However, the patch creating triggers can theoretically be incorporated in Magisk module. Not sure if it fits philosophy of Magisk tho, since its mainly dealing with non-modifying of such data.

Check my post couple of messages up, chmods are required as well.

So correct me if I'm wrong, BUT, the chmods prevent GMS, etc. from auto-updating, so I would need to be mindful of that, correct?
 

GryphonBR

Senior Member
May 6, 2011
206
65
So just after having a few days to test in store and what not. The attest.sql works great for setting the 0, but doesnt' seem to fix the trigger issue or some other issue. dg.db NEEDS to be Read only for adding cards and for in store payment. It had worked once for me as r/w but went to another store and kept getting error trying to pay, changed to r/o boom worked right away same terminal/store/card. Shrug.
Exactly as I originally suggested, RO allows for it to work.

That might just be the issue; I haven't used the one keeping dg.db R/W and I have not had any problems since using the alternate script that keeps it RO.

If you want, here's a copy of the script I'm currently using, and as an extra piece of info I have SQlite installed from Termux:

attest.sql + this = works on my Huawei Mate 20 Pro :good:
You don't need SQL plus the snippet I provided, it should be one or the other. So far, it seems keeping db.dg R/W as attest.sql does prevents GPay from working consistently.

So correct me if I'm wrong, BUT, the chmods prevent GMS, etc. from auto-updating, so I would need to be mindful of that, correct?
That's a supposition, so far. I've yet to see anything clearly stating that from a factual point of view.
 
  • Like
Reactions: dimon222

jsylvia007

Senior Member
Dec 4, 2010
229
48
37
Seekonk
www.jacobsylvia.com
Exactly as I originally suggested, RO allows for it to work.


You don't need SQL plus the snippet I provided, it should be one or the other. So far, it seems keeping db.dg R/W as attest.sql does prevents GPay from working consistently.


That's a supposition, so far. I've yet to see anything clearly stating that from a factual point of view.

Confirming that all I needed to do was apply your script and I was able to add the cards successfully. Before applying I removed the SQL stuff. Won't be able to pay for a bit, but will test as soon as I can.
 

GryphonBR

Senior Member
May 6, 2011
206
65
Confirming that all I needed to do was apply your script and I was able to add the cards successfully. Before applying I removed the SQL stuff. Won't be able to pay for a bit, but will test as soon as I can.
You removed the SQL stuff because you had already used the attest.sql previously, right? If not, you won't be able to use GPay anyway - the SQL commands in the script are shared are needed to get GPay to a work state, then the permission change to dg.db is necessary to ensure the changes are persistent.
 

jsylvia007

Senior Member
Dec 4, 2010
229
48
37
Seekonk
www.jacobsylvia.com
You removed the SQL stuff because you had already used the attest.sql previously, right? If not, you won't be able to use GPay anyway - the SQL commands in the script are shared are needed to get GPay to a work state, then the permission change to dg.db is necessary to ensure the changes are persistent.

Correct. I had already used attest.sql and then you said in a post above that you either need one method or the other, not both. So I ran the file to remove what attest.sql had done and then created a script out of your commands and ran those.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 2
    I having problems activating google pay on rooted Pixel 6 pro. Tried clearing storage of cache of play services, play store, gpay. Adding Gpay sqlite fix, still encountering issues. On magisk canary 23014. Please help

    EDIT: I figured it out.
    A quick summary of what you figured out could be helpful to the next person to come along
  • 61
    The new Google Play services update caused this.

    Temporary workaround:

    1. Disable Google Pay/Find My Device as Device Administrators in Settings > Security & location > Device Administrators.

    2. Search "Google Play services" in the Settings search bar.

    3. Press the three dots and press "Uninstall previous updates".

    4. Download this update - https://www.apkmirror.com/apk/google-inc/google-play-services/google-play-services-14-7-99-release/
    Pick your needed edition (arm or arm64, etc.), download it and install it.

    5. Disable Background data access for Google Play Services and Google Play in their respective App Info pages.

    6. Download Google Pay from the Play Store.

    7. Set up your cards. Enjoy!

    Never EVER update Google Play services manually, until a Magisk update is available that bypasses the upgraded SafetyNet. Note that Google Play services is responsible for adding/verifying the card, not the Google Pay app! Hence why there seems to be an overlay when adding a card/verifying an existing one.

    Tested Google Pay versions:

    2.79.x-2.83.235070858 - working

    Tested Google Play services versions:

    14.7.99, 16.0.86 - working with Magisk 18.1

    14.8.49-16.x- working with Magisk 18.2 Canary
    29
    Ok. I tried this and it worked on gms 17.1.22, allowing one to add cards and pay in store. Warning YMMV, but this is the process I did to get this working. One caveat is that Google pay does not register the "recent transactions" on the Google pay app. Another caveat is that I suspect users will have to reverse some step if gms is updated and then reapply, but this still needs to be confirmed

    Without further ado, here is my process:

    1) download a SQL database editor. I used

    https://play.google.com/store/apps/details?id=com.tomminosoftware.sqliteeditor&hl=en_US

    2) download a terminal emulator program. I used terminus but any terminal emulator should work.

    3) make sure Google pay is forced close, if it is open.

    4) open SQL editor. Navigate to /data/data/com.google.android.gms/databases

    5) open dg.db

    6) change any value that lists "attest" in the name (first column) to 0 in the third column. Mine was showing a value of 10 in the third column for each of these values. (Column c for sqlite databse editor I used)

    7) open the terminal emulator.

    8) get root access (su)

    9) cd /data/data/com.google.android.gms/databases

    10) type: chmod 440 dg.db
    This makes dg.db read only (for owner and group, and no access for world.)

    11) reboot

    I suspect when gms is updated, one will have to go back to steps 10 and 11 and chmod 660 dg.db to allow new keys to be written to the database, and then go back and redo all these steps to reset the attestation values back to 0.

    If there is still an error, verify in sqlite database editor that all attest release keys values in dg.db are 0 when dg.db is read only (owner and group).

    Again, YMMV but this worked for me, so I give it back to the community now.

    Edit: recent activities did show up soon afterwards for the payment method.

    Cheers,
    B.D.
    27
    This thread is inspired by the PoGo Magisk discussion thread. It's meant to keep the clutter of "Google Pay doesn't work" posts out of the main Magisk threads.

    Please use this to discuss issues with Google Pay and possible solutions.


    There's a working solution here:
    https://forum.xda-developers.com/apps/magisk/magisk-google-pay-gms-17-1-22-pie-t3929950
    And a Magisk Module for it here:
    https://forum.xda-developers.com/ap...7-1-22-pie-t3929950/post79643248#post79643248

    For general tips on first getting SafetyNet to pass fully, check here:
    https://www.didgeridoohan.com/magisk/MagiskHide#hn_SafetyNet
    18
    So here's the app to check fails_attestation value. The source code is available here. I may also implement a quick way to delete the gms data folder if you want.
    18
    All you really need to do to fix this is:
    1. Add Google Services to Magisk Hide (if you're on Magisk 18.1 use "su magiskhide --add com.google.android.gms" in terminal)
    2. Add Google Pay and Google Services Framework to Magisk Hide
    3. Go to data/data and rename com.google.android.gms to com.google.android.gms.bak for example (or delete it altogether, but backing up seems safer)

    Reboot and do whatever you like in GPay, it should work now. That's all I've done. I don't think you need to reinstall Magisk.