Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  nodelist  faq  login

Intel CPUs are not defective, they just act that way. -- Henry Spencer

computers / / Re: Battery charge tests - running a battery to 0 frequently - checking re-charge times

Subject: Re: Battery charge tests - running a battery to 0 frequently - checking re-charge times
From: Andy Burnelli
Organization: NNTP Server
Date: Mon, 9 May 2022 21:41 UTC
References: 1 2 3 4 5 6
From: (Andy Burnelli)
Subject: Re: Battery charge tests - running a battery to 0 frequently - checking re-charge times
Date: Mon, 9 May 2022 22:41:21 +0100
Organization: NNTP Server
Message-ID: <t5c1pb$145r$>
References: <t510ud$2t9$> <> <t53fmp$l1h$> <> <t54smd$17mm$> <>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info:; logging-data="37051"; posting-host=""; mail-complaints-to="";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1
Content-Language: en-GB
X-Notice: Filtered by postfilter v. 0.9.2
View all headers wrote:

Notice the tire experiments above where there is precious little
information on the Internet why all the cars that are perfectly aligned in
any given twisty road area wear the tires the exact same abnormal way.

Take a look at the Scotty Kilmer video below, and note particularly that
the photos I've been posting (which I've posted for years) are the _same_
as in Scotty Kilmer's videos (just look and you'll recognize my pictures!).

This is a shot he took of my BMW tires, for example, with wear lined up: He stole my images! :)

Kilmer is a backyard mechanic at best who doesn't know any more about, well, *anything* than any one else.  I wouldn't let this guy change the oil on a car.

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*

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). How to change GSF ID
Maybe changing the GSF ID caused apps with GSF to be indexed wrong? 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.

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). 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. Just don't delete APKs

Which means they can be saved directly onto a Windows mount point. APKs saved into Windows
And then the APKs can simply be slid onto Android to re-install apps. 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. 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. Even Zoom disappeared!

First, let's check if Zoom requires GSF, and when we do, we see it does. 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?

 *Android Developers > Docs> Guides > App install location*
 "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
  App will be installed on sdcard if available
  App will be installed But adb seems to show the location of installed packages.

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       connected to
 C:\> adb devices
      List of devices attached   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

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) (1L) (20L)
      installer=com.aurora.adroid (9L) (85L)
      installer=com.facebook.system (3L) <== note WA is installed, not FB (57L) (1L)       installer=com.sprint.ce.updater (1L) <== note it's a T-Mobile phone (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:
The UID (aka AID) is the backbone of the Android sandboxing, apparently:

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

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

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: \\\DavWWWRoot Where DavWWWRoot can be defined as any location on the phone you want. Windows reads Android root
Namely these are the following locations most people set DavWWWRoot to:
 (o) Root (/)
 (_) SdCard
 (_)Custom folder
 (_)Ext. SdCard
As shown in this graphic using that setting for the Windows mount point: 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

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?
On Usenet, kind-hearted purposefully helpful people carry on polite
discussions which benefit everyone who participates in the conversation.

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

By: Andy Burnelli on Thu, 5 May 2022

116Andy Burnelli
rocksolid light 0.7.2