As I am posting on XDA its obvious that I am into custom rom and development.
So, the reason I'm writing this post its because I recently faced a problem that I found wierd. As I am always flashing custom rom and always switching back and fourth. While doing so I seen that some quick settings tiles are missing in custom roms.
I thought it was problem with custom roms but after some research I found that many other phones are also facing such kind of problems. Android has a bug that causes such issue.
So to fix such there are three solutions
1. The easiest way is to factory reset your device but the downside of this solution is that you will loose your data
2. Second method is by rooting your device and using terminal
Open terminal in android
type
Code:
su
to give root permissions
Code:
settings get secure sysui_qs_tiles
type above line to get the current quick setting tile name if you skip this step you will loose your current tiles
Code:
settings put secure sysui_qs_tiles "YOUROLDLIST,MobileData,Hotspot"
and after following above steps u need to reboot your device
3. Next method is by setting up adb
install adb on your desired system
open cmd or terminal and type
Code:
adb devices
if your device is listed type
Code:
adb shell
and type above two commands
Code:
settings get secure sysui_qs_tiles
Code:
settings put secure sysui_qs_tiles "YOUROLDLIST,MobileData,Hotspot"
YOUROLDLIST= list which you obtain by typing previous command
Code:
adb reboot
the most secure method of above three is last one which is using adb
U will need to find names for specific tiles which is used to restore QS Tiles.
I will try to post all possible tile names.
Name of power menu
Thank you Sv Surve. I also have the same issue. The Power Menu Tile missing in the Quick Settings. I prefer the ADB methode. So what is the name of Power Menu to write in ADB? By the way, my phone is Mi 10 unrooted. So, can use ADB for this?
Related
Hi all, after many attempts to unlock pattern my phone says:
Please enter your google account and password. I´ve attempt enter my google account and password and don´t work..
What i do now? Any idea?
Try this...
So it happens, that my brother locked me out of my own phone :O and i didnt want to wipe, so i searched and searched, until i found this solution which worked flawlessly
Method 1 :
Step 1. Download the Android SDK (http://developer.android.com/sdk/)
Step 2. Make sure to configure the ADB usb interface drivers
Step 3. Plug your G1 into your computer (via usb). (Settings -> Application -> Development -> USB Debugging, must be enabled [it is enabled by default in JesusFreke/CM's releases i think])
Step 4. Open command prompt and enter the following:
Code:
adb -d shell
sqlite3 data/data/com.android.providers.settings/databases/settings.db
update system set value=0 where name='lock_pattern_autolock';
update system set value=0 where name='lockscreen_lockedoutpermanently';
.exit
exit
reboot
Thats it, you'r gh0od :clap:
Method 2 :
Code:
adb -d shell
su
sqlite3 data/data/com.android.providers.settings/databases/settings.db
.header on
.mode column
select * from system;
Now, in the table, find the ID of the two lines called lockscreen.l and lock_pattern, in my case; 3125 and 3126
Code:
update system set value=0 where _id=(replace with your id and remove brackets);
update system set value=0 where _id=(replace with your id and remove brackets);
.exit
reboot
Click to expand...
Click to collapse
Instructions from a slightly dodgy, copyright infringing site, so I copied and pasted them to avoid linking to warez. If you google search for a small part of it, you'll find the original source.
Obviously instructions to be followed at your own risk, since they are for the G1, but I reckon the G2 would be the same (same underlying android code).
If poss, make a nandroid backup first
anon2122 said:
Try this...
Instructions from a slightly dodgy, copyright infringing site, so I copied and pasted them to avoid linking to warez. If you google search for a small part of it, you'll find the original source.
Obviously instructions to be followed at your own risk, since they are for the G1, but I reckon the G2 would be the same (same underlying android code).
If poss, make a nandroid backup first
Click to expand...
Click to collapse
Thanks to u advanced answer...but i make wipe.
I have been experimenting with flashing, etc. and somehow the lockscreen were corrupted and the pattern I was using was not longer valid. I had the fingerprint already setup so I could enter using the rear sensor, but having a corrupted lockscreen is annoying. THis method requires TWRP custom recovery. It is compatible with locked bootloaders and doesn't modify the stock boot or system. It is also compatible with all the AAXON 7 models.
If you have the stock ROM and need TWRP and ADB interface:
A. Setup ADB interface in your PC and device drivers. and connect your terminal to the PC.
B. Setup axon7tool in your computer. Enter into EDL mode by running the command "adb reboot edl" in the command prompt. The terminal will seen to be off.
C. Disable the antivirus and then backup your recovery image using axon7tool running "axon7tool -r recovery". Save the created file in a safe place.
D. Flash tenfar's signed TWRP as a new recovery using axon7tool. It will reboot to system again.
E. Open the command prompt and run:
Code:
adb devices
adb reboot recovery
1. In TWRP , and with the ADB interface properly installed run these the commands from your computer:
Code:
adb devices
adb shell mv /data/system/locksettings.db locksettings.db.old
adb reboot
Now the system will allow you to pass lockscreen without security. In that case you do not need to apply the rest of the steps. Should you continue experimenting issues with the lockscreen, then you should apply the full procedure. Just add the following 2 steps:
2. Open the command prompt and run:
Code:
adb devices
adb reboot recovery
3. When TWRP had fully loaded, run in the command prompt the following commands:
Code:
adb devices
adb shell mv /data/system/gatekeeper.pattern.key gatekeeper.pattern.key.old
adb shell mv /data/system/locksettings.db locksettings.db.old
adb shell mv /data/system/gatekeeper.password.key gatekeeper.password.key.old
adb shell mv /data/system/locksettings.db-shm locksettings.db-shm.old
adb shell mv /data/system/locksettings.db-wal locksettings.db-wal.old
adb reboot
If you want to restore the stock recovery, you just need to rename the recovery-backup.bin file created in step C back to recovery.bin and run the command "axon7tool -w recovery". after that you can enable your antivirus software again. axon7tool can't connect with some antivirus software. I will be editing this OP with links to the procedures required for each step. All of them are in this forums.
Enjoy
@Oki
To fix either " Wrong Pattern " , " Wrong Pin " users only need to delete " /data/system/locksettings.db " from either Terminal/File Explorer with root or TWRP File explorer then Reboot and you'll be good to go .
DrakenFX said:
@Oki
To fix either " Wrong Pattern " , " Wrong Pin " users only need to delete " /data/system/locksettings.db " from either Terminal/File Explorer with root or TWRP File explorer then Reboot and you'll be good to go .
Click to expand...
Click to collapse
Sure! but this guide is intended for people with the stock, unrooted, blocked bootloader who want to remain with a pure stock experience. Usually people without experience rooting devices. This is why I will edit the guide to add all the details to every step.
Could I do this with a pin as well? I restored a backup and it corrupted my password and I have to use the fingerprint on the back to get in.
twilighttony said:
Could I do this with a pin as well? I restored a backup and it corrupted my password and I have to use the fingerprint on the back to get in.
Click to expand...
Click to collapse
Yes, the procedure deletes everything. If you have problems just do the same also with:
gatekeeper.password.key
locksettings.db-shm
locksettings.db-wal
I have updated the OP just to describe the full procedure.
I had this problem earlier today of having the PIN corrupted, but I have it set to require the pin on the first boot.
I fixed it by removing all files ending in ".key" in /system. Not really sure how this compares to removing locksettings.db. Afterward, I put my password back using Google's device manager.
Of course, I am rooted with twrp, so this comes after setting that up.
Masterjuggler said:
I had this problem earlier today of having the PIN corrupted, but I have it set to require the pin on the first boot.
I fixed it by removing all files ending in ".key" in /system. Not really sure how this compares to removing locksettings.db. Afterward, I put my password back using Google's device manager.
Of course, I am rooted with twrp, so this comes after setting that up.
Click to expand...
Click to collapse
The problem of this method is that it only works if the bootloader is unlocked and the phone has the No-verify patch installed.
When you say "No-verify patch," are you talking about removing Google license verification from apps (via an app such as lucky-patcher for instance)? AFAIK that is on a per-app basis and wouldn't affect something like the lockscreen password.
So if the phone has those prerequisites (unlocked, No-verify, TWRP), is there a difference between removing the ".key" files and the locksettings.db? I am not entirely sure what the different files contain, and don't seem to be able to find this information through Google, though I may just not be searching the right set of keywords.
Masterjuggler said:
When you say "No-verify patch," are you talking about removing Google license verification from apps (via an app such as lucky-patcher for instance)? AFAIK that is on a per-app basis and wouldn't affect something like the lockscreen password.
So if the phone has those prerequisites (unlocked, No-verify, TWRP), is there a difference between removing the ".key" files and the locksettings.db? I am not entirely sure what the different files contain, and don't seem to be able to find this information through Google, though I may just not be searching the right set of keywords.
Click to expand...
Click to collapse
No-Verify is an additional security system implementend in the kernel. When No-Verify is active, it checks for the signature of the system partition. If the system was modified, then the system won't boot. This is why after unlocking the bootloader you have to apply No-Verify Patch or any package with the integrated patch such as SuperSU. As you can see, it has nothing to do with the app signature or the lockscreen at all.
The method presented in the OP is valid for most Android phones, and the only prerequisite is to have TWRP installed. It is safe and a lot more recommended than patching the system partition. Patching system or kernel should always be your last resort. usually deleting locksettings.db is enough, and it is a general method that works for almost any locking method.
On B25 and have followed all instructions. Seems this method no longer works :/
So recently i wanted to change my S9 navigation bar color and i tried to use adb shell. All worked fine, i was using these commands:
adb shell
settings put global navigationbar_color <insert value>
settings put global navigationbar_current_color <insert value>
So i read that i if i insert a wrong value then phone may crash and never boot. So I accidentaly pressed CTRL-V (windows cmd prompt) and pressed enter, it didnt paste code but paste ^V symbol instead of color decimal number, so i ended with crashed phone which is not booting now. (Blue led light with samsung logo endless staying on screen).
I really need help to recover all this. I dont want to reset my phone, i want just to change that value back to proper number, but i cant find a way to do. Tried to access phone storage to use sqlite3 on file where global setting is stored, but phone not showing in windows explorer or samsung smart switch.
I just want to find these two strings and add the old value back to them. I dont want to reset phone and loose information just for 2 variables.
P.S. I thought maybe i can create an .apk that change nav bar color's value back and using adb sideload to load it ? I dont know if that's possible.
This guide will walk you through deleting your security PIN via several methods. This guide is for those who have forgotten your security PIN and cannot do a Google reset for some reason. Have restored your phone from an old backup that had a different PIN than your current PIN, and now the Android system is completely confused which PIN to use and isn’t accepting any of them.
You should have a custom recovery installed on your phone, or ADB installed on your computer, but that is beyond the scope of this guide as custom recovery installation methods varies by device. Check Appuals for how to install TWRP on your specific device, or how to install ADB on Windows.
There are two situations you may encounter after restoring from a backup that contained a different PIN than the one you are most recently using.
Device Uses Two Different PINs
This will happen when you have a recent boot PIN, and your backup contains an old screen-lock PIN. So now the device will have two different PINs, which may in fact add to overall device security, but be a headache when you need to remember both PINs.
To resolve this you simply need to reset your PIN in the Android settings. Just go to Settings > Security > Screen Lock, and enter a new PIN. It will overwrite the boot PIN and default back to using just one PIN.
The Device Won’t Accept Any PIN
This is where things get frustrating. In certain cases, your phone may accept the boot PIN, but not a screen unlock PIN. For this, we are going to completely delete the files that store your PIN (yes, your PIN is stored in system files that can be deleted – shocking?).
Delete your Android PIN – TWRP Method
Boot your phone into TWRP recovery.
Go to Advanced > File Manager and navigate to /data/system.
Find the files that end in the .key extension and any files that have “locksettings” in the filename. They will typically be (but vary by manufacturer):
Code:
Gatekeeper.password.key
gatekeeper.pattern.key
locksettings.db
locksettings.db-shm
locksettings.db-wal
After you’ve deleted those files, reboot your phone. You will be greeted by a lock screen, but it will not prompt you for any password or PIN. If it does, you did not delete all the necessary files.
Set a new PIN in your security settings!
Delete your Android PIN – ADB Method
Note: This requires a rooted phone and USB debugging enabled. If USB debugging is not enabled and you are locked out of your phone, you need to try and flash a custom recovery such as TWRP, which can also grant an ADB sideloader.
Connect your phone to your computer via USB and launch an ADB terminal.
Type the following commands into the command prompt:
Code:
adb devices
adb shell
cd /data/system
su
rm *.key
rm *.key
adb reboot
Delete your Android PIN – ADB/SQL Method
Note: This is an alternative ADB method for those who have SQLite3 alongside their ADB installation.
Type the following commands into your ADB/SQL terminal:
Code:
adb shell
cd /data/data/com.android.providers.settings/databases
sqlite3 settings.db
update system set value=0 where name=’lock_pattern_autolock’;
update system set value=0 where name=’lockscreen.lockedoutpermanently’;
.quit
Delete your Android PIN – Flashable Pattern Password Disable.Zip Method
Note: This is for those who have a custom recovery (it doesn’t matter which) installed and want to flash a .zip that will do the work for you.
Download the Pattern Password Disable .zip from here and transfer it to your phone’s SD card.
Reboot into your custom recovery of choice.
Flash the zip and reboot your phone.
I have phone that I am and "owner" user. I've created a user accounts for kids. They used fingerprint to unlock the screen for the user account, but then once the phone asked the PIN to "improve" security, but they forget the pin.. of course. It also looks like the phone switched to FBE (file based encryption) with some OS update. Removing locksettings.db makes the phone unbootable, ale also the owner pin disappears. Is there a way how owner can reset the pin for a user?
I have a root also on this device..
Ok lets first explain the situation
I've been dabbling with Tasker (Paid for version)- getting some automation depending on certain situations (mainly stuff like 'If I'm @ {location} get volumes set high' or ' If Unread msg then vibrate my Amazefit bip watch' - Nothing too complicated using variables / javascript etc)
One situation I want to attempt though is 'If Gpay app is started - turn on NFC, but when I leave the app - turn NFC off'
Now I already know there are 2 'main' ways I can turn on/off NFC in Tasker.. either use 'AutoInput plugin' or use 'Secure Settings'
- I've tried with Autoinput plugin but the problem is that with the free option, you need to watch an Ad every day to use it but of course I can pay for it (its only a couple of quid)
However you can't Install it & pay for it directly from within the plugin - you need to install yet another App (AutoApps) first - & although this one is free - I just don't like adding more bloat to my phone than necessary. Adding both the plugin & this additional App adds (although only a 'minor' amount) up to 20Mb
The other method is give Tasker 'Secure settings' permission
- So I read the 'What to do to give 'Write Secure Settings Permission' to Tasker' (enable Developer mode > Usb Debugging > Install ADB on PC etc etc) & it looks simple enough,
But (a loooong time ago) I tried other 'hacks' & it ended up disastrously (probably I did something wrong with missing a step or something) & I just want to make sure that it IS as simple as it seems and also ask how safe is it
for example
* If I type in the command in ADB - could something go wrong & could it crash/brick the phone ?
* Is this permanent - ie if I turn off/on phone or if I get an OTA update & phone restarts - will it stay, or will I have to repeat the ADB command each time ?
* Will this 'break' official OTA updates (whether security &/or Android firmware) - I once did a firmware update with a step that used ADB (IIRC) & it broke something that prevented any updates from happening
- official OR manual firmware updates
Any help/advice would be appreciated
Cannon_Foddr said:
* If I type in the command in ADB - could something go wrong & could it crash/brick the phone ?
* Is this permanent - ie if I turn off/on phone or if I get an OTA update & phone restarts - will it stay, or will I have to repeat the ADB command each time ?
* Will this 'break' official OTA updates (whether security &/or Android firmware) - I once did a firmware update with a step that used ADB (IIRC) & it broke something that prevented any updates from happening
- official OR manual firmware updates
Click to expand...
Click to collapse
ADB is the door to your phone's Android. It's a tool not meant to be used by John Doe. Wrongly used you can brick your phone. Hence it's by default disabled.
1. Yes, using ADB you can render your phone absolutely useless. If you e.g. enter
Code:
adb shell rm -rf /
then phone gets totally wiped ( really all gets destroyed, it gets naked ) - you can throw it into electric waste.
2. ADB commands aren't persistent, but their results may be.
3. ADB itself breaks nothing: it's a driver installed on your computer that let you access Android's files and launch Android executables.
Thanks for the reply
I doubt I'll use THAT command.
I forgot to mention what tasker's command is
adb shell pm grant net.dinglisch.android.taskerm android.permission.WRITE_SECURE_SETTINGS
Not 100% sure about your last comment though.
ADB allows access to android files so changing android files could break things, which I'm worried about especially with OTA updates etc. (my last phone stopped getting OTA updates when I rooted it despite using official firmware)
However IF I understand the above command all this does is tell the android operating system ('android') to only give the tasker app (which 'Real' name is 'net.dinglisch.android.taskerm') the rights ('permission') to access the required settings ('WRITE_SECURE_SETTINGS') which the NFC on/off toggle is part of (settings >connected devices > connection preferences> nfc) & 'shouldn' t' affect any other files such as OTA (unless OTA is also part of secure setting?)
@Cannon_Foddr
As I can see you until now haven't understood what ADB is, how it works.
Same probably your understanding of what an OTA is.
Personally never would allow 3rd-party apps ( like Tasker ) to modify sensible system settings: Tasker isn't an open-source app, so you can't control what it does in the last run.
It's simply on you to decide whether Tasker is given that right, or not ...
Can't see why 'open-source' has to do with this
IMHO if Open-source - anyone can release similar apps with added extra hidden code that could spy's on you/steal info etc, but a 'closed sourced' app from a long running developer (tasker been around for 10yrs with over 1mil downloads) must mean people seem to trust him/them & if he was 'dodgy' surely he would've been caught out by now
Anyway the Bottom line seems to be
Safe route: pay for plugin & live with extra bloatware
Or
Risky route: give access to secure system resources, see what happens & keep fingers cross nothing does
Thanks for your replies.. I think I may have to sit down & have a long hard think which route I feel more comfortable with
I have been using Automate for about 4 months now. I granted it WRITE_SECURE_SETTINGS and I have not noticed any modifications in my system. Granted I may have not looked specifically for them but as far as braking the system or disruption of OTAs no issues so far
DennisHarrows said:
I have been using Automate for about 4 months now. I granted it WRITE_SECURE_SETTINGS and I have not noticed any modifications in my system. Granted I may have not looked specifically for them but as far as braking the system or disruption of OTAs no issues so far
Click to expand...
Click to collapse
I assume you had to do something like Taskers command then to grant the secure settings
( "adb shell pm grant net.dinglisch.android.taskerm android.permission.WRITE_SECURE_SETTINGS" )
Cannon_Foddr said:
I assume you had to do something like Taskers command then to grant the secure settings
( "adb shell pm grant net.dinglisch.android.taskerm android.permission.WRITE_SECURE_SETTINGS" )
Click to expand...
Click to collapse
Automate is straight forward, there is a toggle for "modify system settings" needed for some tasks to run and one you run the ADB command, it's done