Problem:
I'm an app developer. I have one app that let's you lock the device using Device Administration. One of my users had some conflicts with my app and another. He then removed Device Administration and uninstalled my app, rebooted his phone, and now he cannot access his phone.
He of course cannot use my app to change the password now (since it's uninstalled).
His phone is stock 2.2 LG Optimus V, Virgin Mobile, Rooted.
Question:
I'm needing to find a way that my user can now change his lock code.
I need:
1.) to know an internal class (from com.android.internal) that I could use within an app to change the lock code (just like the system settings do).
OR
2.) to know a command I can use with adb shell to remove or change the phone lock code.
OR
3.) to know the location of the file that stores the lock code information.
Any help is greatly appreciated.
I did actually manage to rewrite a couple pieces of my app, install with adb install, then start it with adb shell am start, and re-enable device admin. So I was able to make it work.
This also worked when my user tried it. Problem Solved.
My phone had a constant wakelock and it was draining my battery.
After doing more research I found that it is because of a recent update to Google Play Services. The Cyanogenmod fix is here:
http://review.cyanogenmod.org/91021
The workaround I used was to enable the service at startup. Only the receivers should be disabled, the service should remain enabled. See the above link for details.
Here is a workaround I use:
Install Script Manager (SManager) from Play Store. https://play.google.com/store/apps/details?id=os.tools.scriptmanager.
Enable Browse as root in SManager (Advanced > Configuration).
From SManager, create a script in /data/local/ with the name 'startsysupservice'.
Edit the script and put the following line in the file:
su -c "pm enable com.google.android.gms/.update.SystemUpdateService"
Mark the following options: Su, Boot, Bg.
Change the radio button from 'Is script' to 'Is executable'. This may not be required for CarbonRom but was when I tested this on CyanogenMod. If you don't select this, the CPU may be constantly doing something so it will actually be worse than before (this selection may have something to do with what shell is used to execute this).
Hit Save. Reboot the phone.
Whenever the phone boots up, it will start the service which should stop the wakelock. It may take a few minutes before the script is run, but eventually the service will start. You can use the 'Disable Service' app to check that it worked.
NOTE: The correct way is for your ROM maintainer to update the sources with the new patch. Unfortunately, many ROMs are no longer maintained (especially for older devices) so this way is a good way to get around this issue for these ROMs. I originally created this for CarbonRom on my P769. I then switched to CyanogenMod 11 by dhiru1602 and this workaround still worked. It should work on other devices as well.
frostinide said:
My phone had a constant wakelock. After doing more research I found that it is because of a recent update to Google Play Services. The Cyanogenmod fix is here:
http://review.cyanogenmod.org/#/c/91021/
The fix I used was to enable the service at startup. Only the receivers should be disabled, the service should remain enabled. See the above link for details.
Here is a workaround I use:
Install Script Manager (SManager) from Play Store. https://play.google.com/store/apps/details?id=os.tools.scriptmanager.
Enable Browse as root in SManager (Advanced > Configuration).
From SManager, create a script in /data/local/ called 'startsysupservice' with the single line:
su -c "pm enable com.google.android.gms/.update.SystemUpdateService"
Mark the following options: Su, Boot, Bg.
Hit Save. Reboot the phone.
Whenever the phone boots up, it will start the service which should stop the wakelock. It may take a few minutes before the script is run, but eventually the service will start. You can use the 'Disable Service' app to check that it worked.
It would be nice if the Cyanogenmod fix in the link above could be merged into CarbonRom and other ROMs for future releases, but I wanted to share this workaround in the meantime. I have P769 with CarbonRom.
Click to expand...
Click to collapse
Interesting info Frost..
and the script is a good idea. By the time I have Oneplus O2 OS all patched up, it will look worse than Frankenstein and I'll never remember all of the operations.
Frost,
Would you detail the differences between "Only the receivers should be disabled, the service should remain enabled"?
Thanks.
JeffDC said:
Would you detail the differences between "Only the receivers should be disabled, the service should remain enabled"?
Click to expand...
Click to collapse
I got that information from the CyanogenMod link I posted. You can see the patch there and see exactly what lines were changed for this fix.
I suggest you read the Android development documentation if you want to know how it all works.
I also found this link, but I can't vouch for its correctness as I don't have enough knowledge of how Android works: http://stackoverflow.com/questions/14548927/android-broadcast-receiver-vs-service
This is a major problem affecting all CM based custom ROMS. The problem is Carbon is not doing anything about it. If you go on their website, there is no new nightly for Galaxy S3 D2LTE - It has been the same ROM since 2014. When you boot the phone, it disables SystemUpdateService. So the phone never sleeps. Waiting for Carbon to Fix this issue.
So here's the real question...
WHERE is this Code within the CM and CM based ROMS that disables SystemUpdateService at boot?
ocd_amp said:
The problem is Carbon is not doing anything about it.
Click to expand...
Click to collapse
If you go to their website, they say they basically stopped working on KitKat except for certain fixes, and are concentrating on Lollipop.
https://carbonrom.org/on-to-sweeter-things/
You can check on their website for more info or if you want to try and contact them. Although I would say it's not really worth it.
I would just use the workaround that I posted (or any other workaround out there). It's not the cleanest solution, but it gets the job done.
ocd_amp said:
WHERE is this Code within the CM and CM based ROMS that disables SystemUpdateService at boot?
Click to expand...
Click to collapse
Check the link I put to the CyanogenMod fix. It has the patch showing the exact line changes and the files that have changed.
update!
Please check this thread.
[MOD] [v7.0.99] Google Play Services with System Update Wake Lock Fix
http://forum.xda-developers.com/one...mod-google-play-services-update-wake-t3078082
frostinide said:
My phone had a constant wakelock and it was draining my battery. I am using CarbonRom on my P769.
After doing more research I found that it is because of a recent update to Google Play Services. The Cyanogenmod fix is here:
http://review.cyanogenmod.org/91021
The workaround I used was to enable the service at startup. Only the receivers should be disabled, the service should remain enabled. See the above link for details.
Here is a workaround I use:
Install Script Manager (SManager) from Play Store. https://play.google.com/store/apps/details?id=os.tools.scriptmanager.
Enable Browse as root in SManager (Advanced > Configuration).
From SManager, create a script in /data/local/ called 'startsysupservice' with the single line:
su -c "pm enable com.google.android.gms/.update.SystemUpdateService"
Mark the following options: Su, Boot, Bg.
Change the radio button from 'Is script' to 'Is executable'. This may not be required for CarbonRom but was when I tested this on CyanogenMod. If you don't select this, the CPU may be constantly doing something so it will actually be worse than before (this selection may have something to do with what shell is used to execute this).
Hit Save. Reboot the phone.
Whenever the phone boots up, it will start the service which should stop the wakelock. It may take a few minutes before the script is run, but eventually the service will start. You can use the 'Disable Service' app to check that it worked.
It would be nice if the Cyanogenmod fix in the link above could be merged into CarbonRom and other ROMs for future releases, but I wanted to share this workaround in the meantime.
Click to expand...
Click to collapse
Thanks a lot buddy.
From a battery drain of anywhere between 20-45% / hour, went straight to 0.3% / hour since the last 4 hours now ( was sleeping myself, but nonetheless the lower end aka 20% drain used to take place when I was sleeping.
Your fix has restored my battery life ( atleast in this short time I do feel that has happened)
Thanks again.
Hi there,
i got rid of the googleupdateservice wakelock by the above hack.
But now i have the fingerprintscannerwakelock keeping my device awake.
Any suggestions for that??
This is the only method I've found to work on my phone to automate the process upon boot. Thanks!!! I've tried about 10 different other ways, from init.d scripts to autoruns to appOps to modified play service apks to you name it.
frostinide said:
My phone had a constant wakelock and it was draining my battery. I am using CarbonRom on my P769.
After doing more research I found that it is because of a recent update to Google Play Services. The Cyanogenmod fix is here:
http://review.cyanogenmod.org/91021
The workaround I used was to enable the service at startup. Only the receivers should be disabled, the service should remain enabled. See the above link for details.
Here is a workaround I use:
Install Script Manager (SManager) from Play Store. https://play.google.com/store/apps/details?id=os.tools.scriptmanager.
Enable Browse as root in SManager (Advanced > Configuration).
From SManager, create a script in /data/local/ called 'startsysupservice' with the single line:
su -c "pm enable com.google.android.gms/.update.SystemUpdateService"
Mark the following options: Su, Boot, Bg.
Change the radio button from 'Is script' to 'Is executable'. This may not be required for CarbonRom but was when I tested this on CyanogenMod. If you don't select this, the CPU may be constantly doing something so it will actually be worse than before (this selection may have something to do with what shell is used to execute this).
Hit Save. Reboot the phone.
Whenever the phone boots up, it will start the service which should stop the wakelock. It may take a few minutes before the script is run, but eventually the service will start. You can use the 'Disable Service' app to check that it worked.
It would be nice if the Cyanogenmod fix in the link above could be merged into CarbonRom and other ROMs for future releases, but I wanted to share this workaround in the meantime.
Click to expand...
Click to collapse
I don't get what you mean by "with the single line:
su -c "pm enable com.google.android.gms/.update.SystemUpdateService"
How do I do that part? All I get is an option to set the name of the script
noob to android said:
But now i have the fingerprintscannerwakelock keeping my device awake.
Any suggestions for that??
Click to expand...
Click to collapse
Sorry, no idea on that one. You should probably create a new post for that.
wasiq224 said:
I don't get what you mean by "with the single line:
su -c "pm enable com.google.android.gms/.update.SystemUpdateService"
How do I do that part? All I get is an option to set the name of the script
Click to expand...
Click to collapse
Put in 'startsysupservice' as the name of the script. Then edit the script (there is an edit button at the top) and put the following line in there:
su -c "pm enable com.google.android.gms/.update.SystemUpdateService"
After it's saved, edit it again to make sure the contents did actually save. If it doesn't work, you may need to save on your sdcard first and then copy it over manually with a root explorer.
It works but you have to say that this file must have changed permissions.
Thanks a lot.
Dru79 said:
It works but you have to say that this file must have changed permissions.
Thanks a lot.
Click to expand...
Click to collapse
Which are the new permissions for the file?
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
Oneplus has started to put Google Dialer along with its new android updates. Although, Google Dialer has many functionalities but, it misses out the native call recording of Oneplus Dialer (without the annoying announcement of calls being recorded of the GOOGLE DIALER).
I tried searching all over the internet but could not get Here is the process of activating native call recording in Oneplus 9R.
Install native Oneplus dailer (you can download from the below link)
https://drive.google.com/file/d/1T4UhfxsmFytd8MTBYN7vZZeVWe8yFAvJ/view
(from https://forum.xda-developers.com/t/...th-call-recording-in-oneplus-8t-nord.4189165/)
Activate USB Debugging on your phone from the developer options.
Go to SETTINGS
ABOUT PHONE
tap few times on BUILD NUMBER before activating DEVELOPER OPTIONS
go back to SETTINGS
go to SYSTEM
DEVELOPER OPTIONS
and activate USB DEBUGGING
Install joneplus tools from Playstore
https://play.google.com/store/apps/details?id=net.jroot3d.joneplustools&hl=en&gl=US
Download Platform tools for android in WINDOWS
USE ADB instruction method from the PLATFORM TOOLS FOLDER
Check if you can find your phone or not
./adb devices
it should show the phone as listed.
after finding your phone as listed, type the following instruction
./adb shell settings put global op_voice_recording_supported_by_mcc 1
This will activate the native call recording feature of ONEPLUS DIALER.
However, the call recorder will be deactivated once you change the sim card or restart your phone. So, you need to install JONEPLUS TOOLS app from GOOGLE PLAYSTORE which will activate the call recording automatically every time you reboot your phone.
You need to provide the permission to joneplus tools by using ADB instruction
./adb shell pm grant net.jroot3d.joneplustools android.permission.WRITE_SECURE_SETTINGS
This will allow joneplus tools to automatically restart and activate the call recording every time the phone reboots. Finally, you will have call recording feature in your beloved ONEPLUS 9R.
Is there any method with root other than the axet call recorder & skvalex?
Thanks in advance.
It's weird, I'm getting the recording option right after installing the dialer apk without performing any adb command or installing any joneplus tool. It's staying Even after reboots, I'm on oos 11.2.LE28DA factory firmware, I'm not rooted and bootloader is locked.. it's weird..
Thanks a lot btw.. pretty useful for me..
Hi there,
OnePlus 9R is one of the most recent devices prior to the OnePlus 10 Pro that just received its global release.
Same thing there, comes with Google Dialer stock. The above apps work on that phone too, but jOnePlus Tools does not install, and the command ./adb shell settings put global op_voice_recording_supported_by_mcc 1 does not execute.
I made a post similar to yours on that forum, with the difference we are stuck without understanding why.
Could you please help us understand why this command does not work on our phones as compared to the Oneplus 9R?
It would help that community a lot.
Here's a link to my post:
Enable Native Call Recording + OP Stock Dialer on OnePlus 10 Pro
Hi guys, Just upgraded from OP7T to OP10 Pro as a European user. Call recording functionality does not come with the device here. Had native call recording enabled on my OP7T through jOnePlus Tools and the likes. Jtools Oneplus does not install...
forum.xda-developers.com
Thanks a lot in advance
Edit: Found a working solution. All I need now is to understand how to write a Tasker task to automate the adb command upon each reboot. This is what jOnePlus Tools normally took care of, but since we can't install it on that device..
Xiaomi, while way better than Huawei in terms of bootloader unlock support etc, still has an issue of bloatware. This is where Dark room comes in. It is a simple app that can run in various modes to disable apps that refuse to be disabled. This would be a nice GUI to disable apps. No more finding package names and uninstalling from adb!
Requirements: another computer or terminal emulator with adb
icebox app:https://www.coolapk.com/apk/web1n.stopapp
You DO NOT need to unlock your bootloader. This can all be done from adb. Just enable it in developer settings.
It supports multiple modes, including shizuku mode.
Be aware that while using device owner mode means it survives restarts, you would have to log out of all accounts on the device including the Xiaomi account, and other users (also called second space) will be deleted. You would have to log back in manually. The app developer has also included a support page for a GUI application which can set device owner (basically it inputs adb commands that delete accounts and then sets device owner)
https://stopapp.https.gs/nonroot.html
Bugs: DO NOT disable critical system apps. You will end up soft bricking your device. System reset is your only option now.