Battery charge tests - running a battery to 0 frequently - checking re-charge times

May 05, 2022 Last reply: 4 years ago 131 Replies

I understand and I don't disagree since I, myself, have a love:hate relationship with Scotty Kilmer, as he seems to spew every bit of nonsense in the book - but - he's also an extremely experienced mechanic.

BTW, this offshoot tangent happened when Jeff Liebermann asked how many apps I have installed if I can lose hundreds without blinking an eye, and the test I just ran moments ago shows 663 installed 3rd-party "packages" and 390 system packages.

I include the documentation of a post I just made below so that the folks on this newsgroup (which is different from that post) can benefit from the tremendous effort in making the solution easily cut & paste for everyone.

If anyone here can help find the missing apps, I'd appreciate your knowledge since I've tried what I know offhand and that has failed so far.

Please see below for a post I just made for this recent thread today: *Using Windows to find hidden files on the Android file system over Wi-Fi*

formatting link

WIP: Using Windows to find hidden files on the Android file system

Help requested from those who know more about finding hidden files on Android from the Windows computer over your local Wi-Fi network.

Recently I updated Android 11 to 12 and all hell broke loose (perhaps because I change my GSF ID which, we can assume, is saved by apps).

formatting link
How to change GSF ID Maybe changing the GSF ID caused apps with GSF to be indexed wrong?
formatting link
Some apps use GSF APIs

This learning experience is perhaps a good thing as it's an opportunity to learn where Android apps typically install their code into.

formatting link

As that location is likely still there (I find it hard to believe that Google _deleted_ the apps off my Android phone during the update).

formatting link
The apps are gone!

Running adb over Wi-Fi (tcpip port 5555) allows me to list packages: C:\> adb shell pm list packages > installed.txt (lists 663 packages) C:\> adb shell pm list packages -s (of which 390 lines are system) C:\> adb shell pm list packages -3 (and where 273 lines are third party) One of which, we would have hoped, would be zoom, but it's not there: C:\> adb shell pm list packages -f | findStr "zoom" (finds nothing)

Luckily, re-installing even hundreds of apps on Android is trivial since all the APKs are automatically _not deleted_ when apps are installed.

formatting link
Just don't delete APKs

Which means they can be saved directly onto a Windows mount point.

formatting link
APKs saved into Windows And then the APKs can simply be slid onto Android to re-install apps.
formatting link
Drag APK from Windows

But even without that, just clicking on the now-dead grayed-out icons brings up the correct _new_ APK in the FOSS google play store client.

formatting link
App is not installed

The point being the problem is NOT to re-install hundreds of APKs, as that part is already trivial.... the problem here is to see if they're _still_ on the Android phone, where I need to know _where_ apps typically go.

Now it's time to look where the missing apps are typically installed into.

Let's take Zoom for example, which seems to have simply disappeared.

formatting link
Even Zoom disappeared!

First, let's check if Zoom requires GSF, and when we do, we see it does.

formatting link
Zoom requires GSF

So now, the question is whether or not Zoom is _already_ installed and perhaps just hidden - but _where_ would zoom be installed onto Android?

formatting link
formatting link

*Android Developers > Docs> Guides > App install location*
formatting link
"android:installLocation manifest attribute"

Apparently the flow is that the developer declares the location android:installLocation=<unset> App will be installed on internal storage only android:installLocation="preferExternal" App will be installed on sdcard if available android:installLocation="auto" App will be installed

But adb seems to show the location of installed packages.

formatting link

So let's try those adb commands over wi-fi (TCPIP port 5555) to see stuff. C:\> adb kill-server C:\> adb tcpip 5555 restarting in TCP mode port: 5555 C:\> adb connect 192.168.0.2:5555 connected to 192.168.0.2:5555 C:\> adb devices List of devices attached 192.168.0.2:5555 device

I was hoping the "disabled" apps option would list zoom, but it didn't: C:\> adb shell pm list packages -d > disabled_apps.txt (219L) Nor did the enabled apps option list zoom (which wasn't expected): C:\> adb shell pm list packages -e > enabled_apps.txt (444L)

I'm not at all sure what the definition of a "disabled" app really is. But what was interesting was disabled apps were mostly in 1 spot. C:\> adb shell pm list packages -d -f > location_disabled_apps.txt package:/data/app/~~{stuff} (208L) package:/product/app/. (3L) package:/system/app/. (3L) package:/system/priv-app/. (5L)

While enabled apps were far more scattered about the Android filesystem. C:\> adb shell pm list packages -e -f > location_enabled_apps.txt (444) package:/apex/. (11L) package:/data/app/~~{stuff} (87L) package:/product/app/. (8L) package:/product/overlay/. (28L) package:/product/priv-app/. (7L) package:/system/app/. (106L) package:/system/carrier/. (4L) package:/system/framework/. (2L) package:/system/priv-app/. (171L) package:/system/system_ext/priv-app/. (8L) package:/vendor/overlay/. (11L) package:/vendor/priv-app/. (1L)

Of course, if I _install_ Zoom, the commands below will tell me where it installed into, but I'm trying to find out if it's really still there.

So let's try this adb command over wi-fi (TCPIP port 5555) to see: C:\> adb shell pm list packages -f -s > sys_package_location.txt (390L) C:\> adb shell pm list packages -f > 3rd_package_location.txt (663L)

Summarizing those files, the system apps seem to be installed into package:/apex/. package:/data/app/. package:/product/app/. package:/product/overlay/. package:/product/priv-app/. package:/system/app/. package:/system/carrier/. package:/system/framework/. package:/system/priv-app/. package:/system/system_ext/priv-app/. package:/vendor/overlay/. package:/vendor/priv-app/.

And the third-party apps seem to be installed into: package:/apex/. (11L) package:/data/app/~~{stuff} (295L) package:/product/app/. (11L) package:/product/overlay/. (28L) package:/product/priv-app/. (7L) package:/system/app/. (109L) package:/system/carrier/priv-app/. (4L) package:/system/framework/. (2L) package:/system/priv-app/. (176L) package:/system/system_ext/priv-app/. (8L) package:/vendor/overlay/. (11L) package:/vendor/priv-app/. (1L)

There are two others options of interest which may help find zoom. C:\> adb shell pm list packages -f -i > installer.txt (663L) installer=com.android.settings (1L) installer=com.android.vending (20L) installer=com.aurora.adroid (9L) installer=com.aurora.store (85L) installer=com.facebook.system (3L) <== note WA is installed, not FB installer=com.google.android.packageinstaller (57L) installer=com.sec.android.app.samsungapps (1L) installer=com.sprint.ce.updater (1L) <== note it's a T-Mobile phone installer=com.tmobile.pr.adapt (4L) installer=null (482)

This might help if I knew what a UID was and what the UID for Zoom is: C:\> adb shell pm list packages -f -U > UID.txt (663L) The UID is apparently particular for an application:

formatting link
The UID (aka AID) is the backbone of the Android sandboxing, apparently:
formatting link

This sounds promising but it lists installed packages apparently: C:\> adb shell pm list packages -i > installer.txt (663L) C:\> adb shell pm list packages -u > uninstaller.txt (663L)

Let's run a quick Windows diff filecompare of these two after sorting: C:\> fc installer.txt uninstaller.txt (206L) <== too confusing

At this point, let's inventory all that is on the Android phone without using adb but simply by using the Windows "dir" command on Android. Pseudocode: dir android_file_system > list_of_all_files_on_android.txt

To more easily search my non-rooted phone, I mounted the Android root file system as a Windows 10 drive letter using a free WebDAV server on Android. *WebDAV Server* by The Olive Tree Free, not ad free, Google free, requires GSF, rated 3.5, 100K+ installs

formatting link

*WebDAV Server - BestDAV PRO* by ZQ Software Free, ad free, Google free, GSF free, rated 4.2, unknown # of installs
formatting link

I'm using "The Olive Tree" WebDav server because I can't figure out the settings to get the "BestDav" WebDav server to allow _write_ from Windows. (If you can solve this problem, I'd appreciate the help you can provide.) For whatever reason, using "The Olive Tree" I can mount everything on Android but the sdcard (which I haven't yet figured out why - but it appears that the Windows adb command _can_ see what's on the SDCARD). (If you can solve this problem, I'd appreciate the help you can provide.)

And then I ran this simple command on Windows to mount the phone: net use Z: \\192.168.0.2@8080\DavWWWRoot Where DavWWWRoot can be defined as any location on the phone you want.

formatting link
Windows reads Android root Namely these are the following locations most people set DavWWWRoot to: (o) Root (/) (_) SdCard (_)DCIM (_)Custom folder (_)Ext. SdCard As shown in this graphic using that setting for the Windows mount point:
formatting link
WebDav set to Android root

So that I could make a list of every file on the Android file system: C:\> Z: Z:\> dir /s/a/l/on/b > c:\tmp\android_filesystem.txt (3914L)

And then I could grep (findstr) for the hidden presence of zoom files. C:\> findstr /i /r /c:"^.*oom" android_filesystem.txt z:\pictures\photoroom z:\pictures\photoroom\photoroom-20220421_205546.png z:\pictures\photoroom\photoroom-20220421_205619.png z:\aurora\store\downloads\com.mushroom.recogniser z:\aurora\store\downloads\com.mushroom.shroomify z:\aurora\store\downloads\com.photoroom.app z:\aurora\store\downloads\com.shroomid z:\aurora\store\downloads\com.shroomid\337\com.shroomid.apk z:\aurora\store\downloads\com.shroomid\337\config.arm64_v8a.apk etc.

Drat. There wasn't a single file on the Android filesystem with "Zoom" anywhere in the name as far as I can tell from this.

Does anyone out there reading this know more about finding hidden files on Android from the Windows computer over your local Wi-Fi network?

I have.

No, this is just an industrial sized fast charger, intended to be used on garages to give enough charge in 10 minutes to a battery so that it can start the car and the client leaves. The client is told he has to replace the battery soon.

It is brutal.

It pushes the 12v battery up to 20 or 30 volts.

The instructions specifically say to disconnect the battery from the car. It is obvious, 20 volts can destroy the car electronics.

This is not done on a good battery.

And yes, I have seen this with my own eyes. You will not easily find it on google.

where have you heard that?

citations required.

what is the make/model of this mythical charger?

it can be. fast charging is harsher on the battery than slow charging, but sometimes it's needed in an emergency. it should not be used routinely.

no it doesn't, since 20-30v will destroy a 12v lead acid battery.

you are confusing volts with amps.

fast chargers supply 20-30 *amps* to rapidly charge a car battery. not volts.

many of them can supply more than that, most of which can also supply significantly higher currents to start the vehicle (not to recharge).

car repair shops have something similar to these:

formatting link
formatting link

it will also destroy the battery.

because good batteries do not need to be recharged.

because what you describe is wrong.

otherwise, it would easily be found with a search.

UPDATE

Since I've tentatively concluded, much to my chagrin, that Android did, indeed, completely wipe out _hundreds_ of apps (zoom among them), perhaps because they were GSF apps which didn't like that I changed the supposedly permanent unique GSF ID tracking identification number...

formatting link
You can change the GSF ID
formatting link
GSF Apps use the GSF ID

I decided to _install_ Zoom (which was easily enough done) and then run the adb commands again to see where it put stuff as an added learning effort.

formatting link
Re-installing Zoom is easy
formatting link
Now let's look where it went

This is where Zoom seems to have installed on Android:

formatting link
Zoom in /data/app/~~{stuff}
formatting link
Zoom in /data/app/~~{stuff} package:/data/app/~~PzJKYsZQ2ZCx6CppblPgRQ==/us.zoom.videomeetings-zGYsIcaI0d-LZ0jXknyD6A==/base.apk=us.zoom.videomeetings

But something is wrong with my Windows dir /s/a/l/on/b since it didn't find the installed zoom location for some unknown-to-me-as-yet reason.

All it found were six new lines (all of which is the saved APK only). C:\> findstr /i /r /c:"^.*zoom" android_filesystem.txt z:\aurora\store\downloads\us.zoom.videomeetings z:\aurora\store\downloads\us.zoom.videomeetings\.651004.download-complete z:\aurora\store\downloads\us.zoom.videomeetings\651004

z:\aurora\store\downloads\us.zoom.videomeetings\651004\config.arm64_v8a.apk z:\aurora\store\downloads\us.zoom.videomeetings\651004\config.xhdpi.apk

z:\aurora\store\downloads\us.zoom.videomeetings\651004\us.zoom.videomeetings.apk

Since this experiment of adding just one app is rarely done, here are the file size differences between Android minus Zoom and Android with Zoom just now. C:\> adb shell pm list packages -f -s > sys_package_location.txt (390L ->

390L) C:\> adb shell pm list packages -f > 3rd_package_location.txt (663L -> 664L) C:\> adb shell pm list packages > installed.txt (663L -> 664L) C:\> adb shell pm list packages -d > disabled_apps.txt (219L -> 299L) C:\> adb shell pm list packages -e > enabled_apps.txt (444L -> 445L) C:\> adb shell pm list packages -f -U > UID.txt (Zoom uid:10588) dir /s/a/l/on/b > c:\tmp\android_filesystem.txt (3914L -> 3920L)

In summary, it does appear that migrating from Android 11 to Android 12 actually deleted hundreds of apps, among them zoom, where there's no trace of those apps on Android after the upgrade other than the Nova launcher saved their location in the well-organized homescreen hierarchy.

Hence re-installing those hundreds of apps is trivial simply because just tapping on the apps opens up the FOSS google play client to install the latest version off the Google Play Store repository - or - I can just as easily slide the APK from Windows over to Android - or - I can just tap on the saved APK on Android (if I had happened to save it there).

I haven't conclusively proven anything yet as to why the migration of Android 11 to Android 12 wiped out hundreds of apps, but I suspect it was simply that the GSF apps misbehaved when they found out that I had changed the supposedly permanent GSF ID.

UPDATE:

I learn more about computers by breaking the rules than by following them.

  1. It's (only?) GSF apps that are gone after upgrading Android 11 to 12
  2. It may be due to the fact I changed the supposedly permanent GSF ID
  3. Luckily Nova knows (almost) exactly how to point to the app installer
  4. However it's a mystery _how_ Nova knows (almost) exactly which it is
  5. Given the app appears to otherwise be wiped completely off the map
  6. However Windows, for some reason, doesn't _find_ the installed app
  7. And yet, adb on Windows can easily find that newly installed app

The main questions that need to be resolved are a. Why can't Windows "dir" find the installed app when Windows adb can? b. How does Nova launcher know exactly which app was wiped off the phone? c. Why should Android upgrades even care about the GSF ID?

Bear in mind there's almost no effort whatsoever in re-installing the hundreds of missing apps; all the effort is going into trying to figure out _why_ and _how_ that happened (as a lot of "magic" seems to have occurred).

Every disaster is an opportunity to learn, where, so far, as I'm going slowly since it's something I look at when I need an app, all the missing apps were GSF apps, which, for now, fits the hypothesis that they never tested Android upgrades for the circumstance that the GSF ID changed.

But why would an Android upgrade even _care_ that a GSF ID had changed? What's it to them?

This is another _new_ learning experience. Why didn't the Windows "dir" command find the zoom installation hierarchy? Where does Zoom put its installed files if not in the system directory?

Yet another new learning experience is the fact that the ease of installing the app is based on "something" (I don't know yet) which is hidden data.

Something about the grayed out icons tells Android exactly which app to find in the FOSS google play store client... however... in one or two cases so far, it did _not_ find the right "something" in that client.

So there's yet more "magic" going on that I don't understand about this yet but it has been a wonderful new learning experience since you can't learn this stuff without some lab work in destructive testing procedures.

that's not a citation, nor did you see that.

what you saw was a 20-30 *amp* charger. not volts.

20-30 volts (3.3-5v/cell) would destroy a 12v lead acid battery, also risking explosion, potentially destroying quite a bit more.

feel free to cite a credible reference to the contrary *and* go back to the garage and take a photo of the charger that you claim was used so that its specs can be verified.

Cite me. I saw it. I am the source.

Nope. Volts. Several electronic devices in my car were destroyed.

that's not how citations work. you can't cite yourself.

what you describe is not how lead acid batteries are charged.

take a photo of the charger and/or find one or more links describing it.

again, take a photo of the charger and/or find some links describing it.

I am a witness.

Nope. It was over a decade ago.

Take my word for it, then you waste your time and find the information. I did that research at the time. What you get is my recollection.

You will not find current information because it is an incorrect and dangerous thing to do; in fact, it destroyed part of the electronics of my car. But I did not know what they were doing at the time or I would have stopped them. I could have sued them.

<snip>

I don't know where that repair shop would have found such a battery charger unless they were using a 24V charger on a 12V battery.

Trying to charge a nominal 12V battery at 30 volts would have unexpected consequences. The battery is a huge load with very low internal resistance so in order for the vehicle electronics to be damaged the charger must also have been supplying enormous amounts of current.

You can hook up a small, unregulated, 20V solar panel to keep a non-AGM car battery charged because the current is so low (a fraction of an amp) that as soon as you connect the battery the load drops the output to around 12 volts.

apparently the only one, since such a device cannot possibly work.

applying 20-30v to a 12v lead acid battery is a *really* bad idea.

it doesn't matter when it was.

all it takes is to find a device that charges 12v lead acid batteries at 20-30v. it doesn't have to be available for purchase anymore.

let's see its specs, how it works, etc.

note that there are chargers that charge *24v* lead acid batteries at ~29v, except that those batteries are not used in cars, nor would a garage have such a charger because they'll never encounter such a vehicle.

24v lead acid batteries (usually two 12v in series) are often found in scooters, wheelchairs, lawn mowers, etc. they also normally have a custom connector for the charger.

your recollection is not substantive.

find a link or even just an article about the existence of such a charger.

what is working against your claim are countless links about charging lead acid batteries at a constant current until the terminal voltage rises to ~2.4v/cell. i already posted the graph of the various stages.

exactly why such a device does not exist.

if it did exist, there would be *something* written about it somewhere, even if it's nothing more than to avoid it.

a bigger question is how many cars were destroyed by this garage.

you should have sued them for destroying your property as well as the manufacturer of the mythical charger, because such a charger, if it did exist, could cause explosions, which would cause all sorts of damage and injuries, possibly fatal.

Nope. Just 12 volt battery, huge garage charger with a setting on "boost" or "super boost" mode.

Something like this, but I don't see documentation on the site:

formatting link

The one they used had wheels.

I think it was rather 20.

Which it did.

CMOS electronics stands 18 volts. Considering that the electronics (the entire display setup) failed maybe two months later, the voltage on the car would have been around 20. The radio survived because it was disconnected. The car was diesel, so no ignition. I think the remote door opener also failed.

The charger was used by someone that was not a full mechanic, but one that was usually on the front desk. A full mechanic would have known that the instructions for that mode say to disconnect the battery from the car because you can fry the electronics. And she did fry the electronics, but unfortunately not instantly, not that minute, so we did not made the connection.

And yes, I did read the documentation, two years later the incident. I found it somewhere, but I do not know the keyword to find it again.

Do you also have a picture of a stack of books to "prove" it?

You are so entirely STUPIDLY wrong it's not even funny.

No you are not. You are an ignorant fool.

those modes are high *current*.

formatting link
formatting link

€ Charging current: 18 A

it's also a 12/24v charger. maybe someone set it to 24v, which would quickly destroy a 12v battery and anything connected to it that was expecting only 12v (actually 13.8v when the engine is running).

most high current chargers do.

formatting link
20 amps, sure.

20 volts, definitely no.

if it was manually set for 24v batteries, it would be ~29v.

here's a graph of charging three types of 12v lead acid batteries. note that the threshold voltage is slightly different for each, and always under 15v. double the values for a 24 battery.

formatting link

You are a moron who has no idea what you saw, or is simply making s*it up.

And you got the details wrong.

Not a chance in hell. I've seen a lead-acid battery pop its acid when the wrong voltage charger was used, back in the days when VWs had lower volt batteries that the standard 12V.

There we go, you cannot find any source to back up your claim. Congratulations, you have now proved your claim is bullshit.

No you didn't.

Which is worthless.

That is AMPS that are boosted, you numpty moron, not volts.

Translation:

Battery chargers for charging free electrolyte (WET) batteries with 12/24 V voltage, protection against overloads and inversions of polarity. Equipped with an ammeter and normal, fast load selector (BOOST) and ammeter.

And:

Charging current 18 A (12 V) 12 A (24 V)

Ah, your confusion is that "Boost" doesn't increase the voltage being used, it increases the current to a level great enough to start the vehicle even when there is a dead battery loading down the electrical system. See

formatting link
. At 250 amps you can pretty much start any vehicle, even one where the vehicle's battery has close to zero internal resistance.

I have an SUV that I don't drive very often. If I let the battery run down completely I can't even start it with a 50 amp booster, I have to charge the battery for a while (or use a Li-Ion jumper battery which is able to provide a large amount of current for a short time).

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required