Huge battery drain, no doze but a possible fix!

[Clanceeinfinity]

Acknowledgements

• [X] I have chosen an appropriate title.
• [X] All requested information has been provided properly.
• [X] This is not a feature request.
• [X] This issue is not a duplicate of an existing issue.
• [X] The issue is solely related to this GSI.
• [X] This issue occurs with the latest available build.
• [X] I am not running a custom vendor on my device.
• [X] This issue is not kernel related.
• [X] This issue is not related to Magisk/KernelSU/APatch.

Info

• Device: duo2 and tab s7 (where i made the discovery)
• GSI version: every recent upload
• Vendor version: idk

Expected Behavior

doze should activate

Current Behavior

doze should activate but it doesn't, also screen on time is drastically reduced and the cpu drains a lot

Possible Solution

I got my duo2 recently so i thought this was just normal, but yesterday i flashed a similar aosp based gsi on my galaxy tab s7, which has always had outstanding battery life. Suddenly i experienced exactly the same issues as on the duo2, with again doze not activating.

I talked with the maintainer, we came to the conclusion that an app must be crashing in the background, in this case it was com.android.phone. I first tried to disable it with adb, this didn't work. Then i tried to force uninstall it with ./adb shell pm uninstall -k --user 0 com.android.phone

This worked and completely fixed the drain from an idle 4-5% an hour to 0% an hour. My tab s7 is wifi only so i don't know if this will mess with the calling experience.

Steps to Reproduce

1. turn of screen
2. get surprised by a lot of drain
3. ...

Logs

No response

Additional context

both devices, s7 and duo2, are on 14(AP2A.240805.005)

[Archfx]

This is great information, may I know the link for the tabs7 repository? There were complaints about unacceptable battery drain. This is a great pointer for a potential fix in that direction.

[Clanceeinfinity]

here is the link of the gsi build (odin flash able build) and the telegram group! https://xdaforums.com/t/04-10-2024-rom-t870-gsi-aosp-android-14-gapps.4663516/ https://t.me/gts7x

[Clanceeinfinity]

btw i did try the same on the duo2 but my sim couldn't be recognised anymore 😬 i used this command to revert that action: adb shell cmd package install-existing com.android.phone

[Archfx]

We will have to patch the cause of the issue. Let's see how it goes.

[Archfx]

Did you observe any particular error in the log file during idle? Especially did you observe any improvement after deleting com.android.phone?

I found this on the log

E NetworkStats: java.lang.NullPointerException: Attempt to invoke interface method 'boolean android.net.connectivity.com.android.net.module.util.IBpfMap.deleteEntry(android.net.connectivity.com.android.net.module.util.Struct)' on a null object reference o

Backtracked to the root cause for this as well. However, I don't think fixing the NullPointerException will fix the battery drain. What I think is some other application is creating the deleteEntry NullPointerException. If you can confirm that removing com.android.phone fixed the battery drain, it would be helpful.

[TuayFu]

for this issue i found the battery drain on A14 and the phone seem to drain the battery even if it's in folded position and it's always warm. When i tried checking with the battery app i shows that the screen is draining the battery. So, I turn off the lock screen clock and the screen server and this problem seem to perish. Hope this helps

[Clanceeinfinity]

screen saver is off my default though or not? what exactly do you mean with lock screen clock??

[TuayFu]

Just the option of what to show on the lock screen, i just turn it off altogether. I also turn off the lift to wake option. Hope this helps

[Archfx]

The battery drain on the A15 versions is pretty normal. Therefore I'm closing this issue.

[Clanceeinfinity]

does anybody else still experience this issue? i still lose well over 50% per night with idle drain.

[Clanceeinfinity]

The battery drain on the A15 versions is pretty normal. Therefore I'm closing this issue.

do you use the duo2 / was this issue present on the duo1 too? Also did you reset your device before flashing android 14? For me the bug is still present and i didn't reset, maybe it's an app in the background that still crashes like i theorised...

[Archfx]

I think @Ethanol10 found the source of this battery drain, this issue is only in Duo2 and it is due to Vo-LTE. However, at the moment, what we found was that Microsoft has used a proprietary implementation for Vo-LTE which we have to reverse engineer the API calls to make it work.

For now, your solution is the only option we have!

[Clanceeinfinity]

oh ok because i noticed the drain was also there when i turned mobile data off, in the battery app, it reported the cpu draining extreme amounts. Is there a way to turn volte off?

[Archfx]

oh ok because i noticed the drain was also there when i turned mobile data off, in the battery app, it reported the cpu draining extreme amounts. Is there a way to turn volte off?

Can you do the following commands from the ADB and report the output

adb shell
cat /sys/devices/platform/soc/soc:surface_util/ms_pen_charger/ms_pen_charger

Just want to see if the charger is always on in your device.

[Clanceeinfinity]

ill try as soon as my pc works again!

[oilcan-productions]

@Archfx tried running the command on my Duo 2 and I get Permission denied. when booted to A15. I have a Pen attached and it is charging so I assume the charger is on. I do experience the battery drain as well.

Turning off VoLTE does not change the behavior though

[Archfx]

@Archfx tried running the command on my Duo 2 and I get Permission denied. when booted to A15. I have a Pen attached and it is charging so I assume the charger is on. I do experience the battery drain as well.

Turning off VoLTE does not change the behavior though

Actually, thanks for the information. @Ethanol10 did a lot of reverse engineering on the duo2 and we identified this particular concern, you are correct it is not related to VoLTE and it is due to the pen charger, I couldn't update the issue.

We already implemented pen charging functionality (to control it from the notification bar) after a lot of trial and error, but it is still under testing. This issue on the duo2 will be solved really soon!

[oilcan-productions]

Thanks for the update. I am looking forward to the fix

[Archfx]

Finally, duo2 has the pen charging ability. Great work @Ethanol10!

If you have this issue, turn off the wireless pen charger from Settings -> Duo-De Treble Settings.

[Darkaxt]

I am not sure if I should ask here or a new issue, but I was stupid enough to delete com.android.phone apk using ShizukuTools and now, no matter how many times I reflash the rom, the settings apk fail to open directly, and when opened indirectly it crashes on the network settings. The error logs shows the following: 12-17 10:27:19.006 14974 14974 E AndroidRuntime: java.lang.RuntimeException: Unable to start activity ComponentInfo{com.android.settings/com.android.settings.Settings$NetworkDashboardActivity}: java.lang.IllegalStateException: telephony service is null. 12-17 10:27:19.006 14974 14974 E AndroidRuntime: at com.android.settings.network.CellularSecurityPreferenceController.areNotificationsEnabled(CellularSecurityPreferenceController.java:160) 12-17 10:27:19.006 14974 14974 E AndroidRuntime: at com.android.settings.network.CellularSecurityPreferenceController.getAvailabilityStatus(CellularSecurityPreferenceController.java:100) 12-17 10:27:19.006 14974 14974 E AndroidRuntime: at com.android.settings.core.BasePreferenceController.isAvailable(BasePreferenceController.java:260) 12-17 10:27:19.006 14974 14974 E AndroidRuntime: at com.android.settingslib.core.AbstractPreferenceController.displayPreference(AbstractPreferenceController.java:59) 12-17 10:27:19.006 14974 14974 E AndroidRuntime: at com.android.settings.core.BasePreferenceController.displayPreference(BasePreferenceController.java:282) 12-17 10:27:19.006 14974 14974 E AndroidRuntime: at com.android.settings.network.CellularSecurityPreferenceController.displayPreference(CellularSecurityPreferenceController.java:64) 12-17 10:27:19.006 14974 14974 E AndroidRuntime: at com.android.settings.dashboard.DashboardFragment.lambda$displayResourceTilesToScreen$8(DashboardFragment.java:379) 12-17 10:27:19.006 14974 14974 E AndroidRuntime: at com.android.settings.dashboard.DashboardFragment.$r8$lambda$dJyii1AB-wnnohgJau5iUqpyrf0(DashboardFragment.java:0) 12-17 10:27:19.006 14974 14974 E AndroidRuntime: at com.android.settings.dashboard.DashboardFragment$$ExternalSyntheticLambda6.accept(R8$$SyntheticClass:0) 12-17 10:27:19.006 14974 14974 E AndroidRuntime: at com.android.settings.dashboard.DashboardFragment.displayResourceTilesToScreen(DashboardFragment.java:378) 12-17 10:27:19.006 14974 14974 E AndroidRuntime: at com.android.settings.dashboard.DashboardFragment.displayResourceTiles(DashboardFragment.java:370) 12-17 10:27:19.006 14974 14974 E AndroidRuntime: at com.android.settings.dashboard.DashboardFragment.refreshAllPreferences(DashboardFragment.java:433) 12-17 10:27:19.006 14974 14974 E AndroidRuntime: at com.android.settings.dashboard.DashboardFragment.onCreatePreferences(DashboardFragment.java:206) 12-17 10:27:19.006 14974 14974 E AndroidRuntime: at com.android.settingslib.core.lifecycle.ObservablePreferenceFragment.onCreate(ObservablePreferenceFragment.java:61) 12-17 10:27:19.006 14974 14974 E AndroidRuntime: at com.android.settings.SettingsPreferenceFragment.onCreate(SettingsPreferenceFragment.java:138) 12-17 10:27:19.006 14974 14974 E AndroidRuntime: at com.android.settings.dashboard.DashboardFragment.onCreate(DashboardFragment.java:165) 12-17 10:27:19.006 14974 14974 E AndroidRuntime: at com.android.settings.SettingsActivity.switchToFragment(SettingsActivity.java:723) 12-17 10:27:19.006 14974 14974 E AndroidRuntime: at com.android.settings.SettingsActivity.launchSettingFragment(SettingsActivity.java:515) 12-17 10:27:19.006 14974 14974 E AndroidRuntime: at com.android.settings.SettingsActivity.createUiFromIntent(SettingsActivity.java:324) 12-17 10:27:19.006 14974 14974 E AndroidRuntime: at com.android.settings.SettingsActivity.onCreate(SettingsActivity.java:283)

[Archfx]

I am not sure if I should ask here or a new issue, but I was stupid enough to delete com.android.phone apk using ShizukuTools and now, no matter how many times I reflash the rom, the settings apk fail to open directly, and when opened indirectly it crashes on the network settings. The error logs shows the following: `12-17 10:27:19.006 14974 14974 E AndroidRuntime: java.lang.RuntimeException: Unable to start activity

If you deleted a system app, it should be restored upon a reflash. What is the build number you are currently on?

[Clanceeinfinity]

did you try to use this command to force install the app again? adb shell cmd package install-existing com.android.phone