I've noticed that since a few days ago, every day, even though I don't use them, the Google Maps and Google Search apps pop up in the battery usage with high percentages. I don't know why this is happening, especially because it didn't happen before, and I've already disabled location reporting...
I'm running CM10 M1, with stock CM kernel.
Bumping...
It's the app. Maps is a notorious battery drainer and Google search could just be Google Now.
Sign out of Latitude, disable location services (all of them) and as an extra step with an app such as Gemini App manager or Autostarts stop all autorun instances of Maps.
For Google Now, just disable it.
So in an effort to save battery life I've used an Xposed module to disable wakelocks on Google Play Services. My questions is: what am I not going to get because of this? Location based Google Now items? Certain functionality? What difference am I going to see in my phone?
Any way to disable "you must have Google play services to run (name of app that doesn
Title cut off, rest should say "doesn't require Google play services to run"
I only use the play store basically, and have no issues with manually enabling before checking for app updates or to download new apps (on my newer device, my older device doesn't even require them for the play store at all)
But things like ccleaner, my emoji keyboard, a few other apps I can't think, of annoyingly claim to need these services to run... While I'm actively running them and using them just fine without.
On a device without the option "disable notifications for this app"either within the app itself, or within my older 4.0.4 device that runs just fine despite it being older... How can I get rid of these annoyances?
Play services are a huge battery and ram hog which I keep disabled unless needed. So any "just install play services" comments isn't exactly what I'm looking for...
I've looked around in disable service (the app) for these apps, unable to find anything looking relevant.
Any help would be appreciated
Play Services are often used for authentication reasons. Meaning the apps look if you have a genuine version. For freemium apps they check for any in app purchases you might have done.
Other common cases are for push notifications or location services etc. These are often only minor or optional features of apps. That's why they usually work nonetheless without having Play Services active.
The only easy option is to use an alternative app store like the Amazon App Store or F-Droid. All the apps over there are pretty much guaranteed to work without Play Services.
There are also some projects out there that aim for a system without Play Services. A quick search should yield quite some results.
If you are rooted and capable of using XPosed, then there is a module in the repo somewhere that does exactly what you are looking for - hiding the pop up.
Can't remember the name right now and don't know if it is still maintained, but searching the modules should provide it to you.
However, Google Play Service shouldn't be so much of a power drainer any more. Beginning with Android 6 / M the battery optimizations are quite enormous, even though the Play Services are excluded from the system wide optimization (because they take care of these optimizations). To further improve the footprint, you could disable the location services and wireless scanning services.
So there are news of Google collecting Location Even With GPS Turned Off. But I was really thinking to abort using google services not because of this location tracking but also battery draining from google's wakelock which a serious issue to me as no matter what rom am i using playstore will always drain battery ... So i am thinking to go different alternative service i need maps so obviously i use google maps alot but i need its alternate app and same follow with sync service ( i can adjust it to manual no problem ) but i need those services which will not drain my battery and seriously those secret tracking services. If you want to make fun go away. If any dev or group can make alternate google services pls response here . I could be beta tester.
There is already a project that goes along what you want. Search for microg (I think it's called) it limits the Google services and uses alternatives for others.
Here is the issue you will find. Android is made to use Google services and without it, a lot of things just will not work completely right. Like location based services.
Ok, I've got a Blu Life One X3 with BLU_L0150WW_V7.0.04.13_GENERIC ROM, Android Nougat 7.0.04.13, rooted with TWRP as bootloader and Magisk as root. AFWall+ is the iptables firewall, and the systemless Xposed Framework is installed as a module in Magisk.
All syncing is turned off and disabled, most of the Google pre-installed apps have been removed from the phone. Only the following remain:
Google Services Framework
Google Play Store
Google Play Services
Google Partner Setup
Google Account Manager
Contacts
Google Phone (merely because I can't find contacts and dialer that properly hook into Android... I will eventually)
Removed:
Google Chrome (internet activity tracking)
Google Tag Manager (tag & pixel tracking)
Google Play Music (lifestyle demography)
Google Play Movies & TV (lifestyle demography)
Google Maps (location tracking)
Google - Quick Search Box (search tracking)
Google YouTube (lifestyle demography)
Google TalkBack / Android Accessibility Suite
Google Drive (lifestyle demography)
Google Duo (audiovisual demography)
Google Contacts Sync (association demography)
Google Backup Transport
Google Market Feedback Agent
Google Calculator
Google Calendar (lifestyle demography)
Google Gmail (lifestyle and association demography)
Google Text-To-Speech
Google Japanese Input
Google SMS - Messages (SMS tracking)
Google Photos (lifestyle demography)
Google Carrier Services
OK Google voice assistant (audio monitoring)
Work Profile Setup
GBoard Google Keyboard (keylogger tracking)
ASIDE:
----------
Yes, GBoard logs keystrokes... Google's own privacy statement about the keyboard reads: "Gboard will remember words you type to help you with spelling or to predict searches you might be interested in."
Maybe you trust that "spelling or to predict searches" is all Google is using their keylogger keyboard for, but I don't.
----------
I've been browsing through the phone's file system, doing a lot of research, and editing .xml files to disable all the jobs that Google starts when the phone boots, and to retract permissions that Google has taken the liberty of using... this reduces CPU utilization and increases battery life. The phone works beautifully, doing what I want it to do (and nothing more), and going for days before requiring a charge.
I've seen no adverse effects from this, save for the issue at hand... that of Google Play Services trying to push a new ROM (BLU_L0150WW_V7.0.04.14_GENERIC), despite me having disabled OTA updates and Google Play Store automatic updates. Google Play Services reboots my phone at midnight each night in attempting to install the update, against my will and without my express consent.
When Google becomes the data-filching malware you cannot turn off, it's time to put Google on a short leash.
Google Play Services downloads via WiFi a .zip file named update_s.zip to /cache, then reboots the phone at midnight. It expects to reboot to fastboot, but that no longer works because I've got TWRP as bootloader, so it boots to the main TWRP screen and just sits there until I reboot it. If the update_s.zip file is allowed to remain in /cache until the next night, Google Play Services won't re-download it, it'll simply reboot the phone in attempting to install it.
I've removed Scheduled Power On/Off (package:/system/vendor/app/SchedulePowerOnOff/SchedulePowerOnOff.apk=com.mediatek.schpwronoff), so it cannot be the cause of the reboots, it's definitely Google Play Services. I've watched system activity via adb logcat and can clearly see that the culprit is Google Play Services.
Even if the update could successfully execute, I wouldn't install it... why is Google pushing a phone manufacturer's ROM, and why are they doing so against my will and in contradiction to the disabled OTA and Google Play Store automatic updates? Why didn't Blu push the update? I suspect they're pushing the ROM to get their permissions back... I'm no longer a cash cow for them, and they desperately want to make money off my info.
I see no way of disabling this behavior, and I've certainly not authorized Google to push system updates to my phone, nor to reboot my phone... they must be brought to heel and forced (via litigation, if necessary) to respect personal property rights. This is illegal under California Penal Code 502(c), Comprehensive Computer Data Access and Fraud Act.
This is tantamount to a mechanic creeping into someone's garage at midnight each night and letting the air out of someone's car tires because that someone doesn't use that mechanic's services. This is tantamount to a refrigerator manufacturer sneaking into someone's home at midnight each night and unplugging the refrigerator because it's made by another manufacturer.
How do I disable this behavior?
So far, the only thing in the file system that I can find that pertains to this is:
/service_contexts
#Other Services
GoogleOtaBinder ubject_rta_agent_service:s0
Anyone know what this is? I can pull the file to the computer in TWRP Recovery Mode, comment out that line and push it back to the phone to see if that ends the behavior. Before I do so, though, I'm going to wait until tomorrow... tonight, I've deleted the /cache/update_s.zip file, and I'm keeping internet connections down (and, for good measure, the firewall in lockdown mode), to see how Google Play Services reacts.
I'm betting it'll do this when that line is commented out:
Code:
private boolean setInstallInfo(String strPkgPath, String strTarVer) {
Xlog.i(TAG, "onSetRebootRecoveryFlag");
try {
IBinder binder = ServiceManager.getService("GoogleOtaBinder");
SystemUpdateBinder agent = SystemUpdateBinder.Stub.asInterface(binder);
if (agent == null) {
Xlog.e(TAG, "agent is null");
return false;
The phone did not reboot last night with update_s.zip deleted from /cache and all internet connections down.
This means Google Play Services is performing unannounced, unsolicited and unwanted remote operations upon a computer system, while disregarding the 'Settings' > 'Developer Options' > 'Automatic System Updates' being disabled, a blatant violation of CA Penal Code 502(c). Anyone up for a class-action lawsuit?
Google Play Services / GoogleOtaBinder doesn't query the 'Automatic System Updates' setting prior to performing its above-described operations, and I have a hard time believing this was just an oversight on the part of Google... it would seem far more likely (given that they're a multi-billion dollar company which hires highly competent programmers, given that they have a financial incentive to regain deleted apps or retracted permissions which a knowledgeable user might delete / retract, given the unannounced nature of the operations they're attempting, given the midnight time at which they're attempting to perform those operations) that the bypassing of the 'Automatic System Updates' setting is quite intentional as means of Google surreptitiously regaining apps deleted or permissions retracted so they can continue to gather personal data via the phone.
Tonight I'm disabling the registration of the service context for GoogleOtaBinder... let's see what kind of fits Google Play Services throws. :silly:
{EDIT}
Hrmph... /service_contexts is written to during boot to register Google's service contexts... I'm going to have to dig a bit deeper to permanently disable GoogleOtaBinder.
Until then, I'm renaming /system/etc/security/otacerts.zip so GoogleOtaBinder cannot communicate with the OTA update server.
There remains the nagging questions:
- Why does Google's OTA system updater disregard user settings which disable automatic system updates?
- Why does Google reboot the phone unannounced?
- Why does Google reboot the phone unannounced, at midnight, when the phone is least likely to be monitored?
- Why does Google dynamically write GoogleOtaBinder into /service_contexts at boot, rather than hard-coding it in so it can easily be commented out, thereby disabling Google OTA updates?
- Why doesn't Google provide a user-interface-accessible means of turning off Google OTA updates?
Well, that did the trick. Renaming /system/etc/security/otacerts.zip so GoogleOtaBinder cannot communicate with the OTA update server does away with Google Play Services' attempts at forcing a system update.
Now to dig into the files and figure out where they're writing to /service_contexts from during boot. I'm going to pull every bit of the Google-weed out by the roots that I can.