Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.mobile.android > #156271 > unrolled thread

Eliminate Gemini from Android Phone?

Back to article view | Back to comp.mobile.android

Contents

  Eliminate Gemini from Android Phone? Mike Copeland <mrc2323@cox.net> - 2026-10-04 21:07 -0700
    Re: Eliminate Gemini from Android Phone? VanguardLH <V@nguard.LH> - 2026-10-04 23:50 -0500
      Re: Eliminate Gemini from Android Phone? Maria Sophia <mariasophia@comprehension.com> - 2026-10-05 04:48 -0300
        Re: Eliminate Gemini from Android Phone? VanguardLH <V@nguard.LH> - 2026-10-05 03:32 -0500
          Re: Eliminate Gemini from Android Phone? Maria Sophia <mariasophia@comprehension.com> - 2026-10-05 12:02 -0300
            Re: Eliminate Gemini from Android Phone? VanguardLH <V@nguard.LH> - 2026-10-05 22:10 -0500
              Re: Eliminate Gemini from Android Phone? Maria Sophia <mariasophia@comprehension.com> - 2026-10-06 14:30 -0300
        Re: Eliminate Gemini from Android Phone? Arno Welzel <usenet@arnowelzel.de> - 2026-10-05 13:45 +0200
          Re: Eliminate Gemini from Android Phone? Maria Sophia <mariasophia@comprehension.com> - 2026-10-05 12:01 -0300
            Re: Eliminate Gemini from Android Phone? Arno Welzel <usenet@arnowelzel.de> - 2026-10-06 10:59 +0200
              Re: Eliminate Gemini from Android Phone? Maria Sophia <mariasophia@comprehension.com> - 2026-10-06 14:38 -0300
                Re: Eliminate Gemini from Android Phone? Arno Welzel <usenet@arnowelzel.de> - 2026-10-08 17:57 +0200
                  Re: Eliminate Gemini from Android Phone? Maria Sophia <mariasophia@comprehension.com> - 2026-10-08 15:48 -0700
        Re: Eliminate Gemini from Android Phone? "Carlos E. R." <robin_listas@es.invalid> - 2026-10-06 12:18 +0200
          Re: Eliminate Gemini from Android Phone? Arno Welzel <usenet@arnowelzel.de> - 2026-10-06 12:47 +0200
            Re: Eliminate Gemini from Android Phone? Maria Sophia <mariasophia@comprehension.com> - 2026-10-06 15:31 -0300
              Re: Eliminate Gemini from Android Phone? "Carlos E. R." <robin_listas@es.invalid> - 2026-10-06 20:53 +0200
                Re: Eliminate Gemini from Android Phone? Maria Sophia <mariasophia@comprehension.com> - 2026-10-06 16:28 -0300
                  Re: Eliminate Gemini from Android Phone? "Carlos E. R." <robin_listas@es.invalid> - 2026-10-06 21:51 +0200
                    Re: Eliminate Gemini from Android Phone? Maria Sophia <mariasophia@comprehension.com> - 2026-10-07 02:41 -0300
    Re: Eliminate Gemini from Android Phone? micky <NONONOmisc07@fmguy.com> - 2026-10-05 09:49 +0300
      Re: Eliminate Gemini from Android Phone? "s|b" <me@privacy.invalid> - 2026-10-05 14:53 +0200
        Re: Eliminate Gemini from Android Phone? Maria Sophia <mariasophia@comprehension.com> - 2026-10-05 12:23 -0300
          Re: Eliminate Gemini from Android Phone? Old McDonald <eieio@patch.corn> - 2026-10-06 00:12 -0700
            Re: Eliminate Gemini from Android Phone? Maria Sophia <mariasophia@comprehension.com> - 2026-10-06 15:38 -0300
              Re: Eliminate Gemini from Android Phone? Old McDonald <eieio@patch.corn> - 2026-10-06 12:59 -0700
          Re: Eliminate Gemini from Android Phone? Arno Welzel <usenet@arnowelzel.de> - 2026-10-06 11:00 +0200
            Re: Eliminate Gemini from Android Phone? Maria Sophia <mariasophia@comprehension.com> - 2026-10-06 15:43 -0300
              Re: Eliminate Gemini from Android Phone? Maria Sophia <mariasophia@comprehension.com> - 2026-10-06 15:49 -0300
              Re: Eliminate Gemini from Android Phone? Arno Welzel <usenet@arnowelzel.de> - 2026-10-08 18:03 +0200
                Re: Eliminate Gemini from Android Phone? Philippe <p.naudin+nntp@free.fr> - 2026-10-08 20:34 +0200
                Re: Eliminate Gemini from Android Phone? Maria Sophia <mariasophia@comprehension.com> - 2026-10-08 15:41 -0700
        Re: Eliminate Gemini from Android Phone? Nuno Silva <nunojsilva@invalid.invalid> - 2026-10-06 23:02 +0100
          Re: Eliminate Gemini from Android Phone? Old McDonald <eieio@patch.corn> - 2026-10-06 18:51 -0700
          Re: Eliminate Gemini from Android Phone? Frank Slootweg <this@ddress.is.invalid> - 2026-10-07 14:52 +0000
    Re: Eliminate Gemini from Android Phone? Arno Welzel <usenet@arnowelzel.de> - 2026-10-05 13:45 +0200
      Re: Eliminate Gemini from Android Phone? Maria Sophia <mariasophia@comprehension.com> - 2026-10-05 12:05 -0300
        Re: Eliminate Gemini from Android Phone? Arno Welzel <usenet@arnowelzel.de> - 2026-10-06 11:01 +0200
          Re: Eliminate Gemini from Android Phone? Maria Sophia <mariasophia@comprehension.com> - 2026-10-06 15:45 -0300

Page 1 of 2  [1] 2  Next page →

#156271 — Eliminate Gemini from Android Phone?

   Is there a way to remove Gemini from my Android phone (safely)?  This 
intrusive software app just appeared on my phone some months go, and (1) 
I have no need for it and (2) it's just the kind of cr*p I don't want.  
I just want to remove it, but I don't know if it's possible.  Please 
advise.  TIA

-- 
This email has been checked for viruses by Avast antivirus software.
www.avast.com

[toc] | [next] | [standalone]

#156272

Mike Copeland <mrc2323@cox.net> wrote:

> Is there a way to remove Gemini from my Android phone (safely)?  This
> intrusive software app just appeared on my phone some months go, and
> (1) I have no need for it and (2) it's just the kind of cr*p I don't
> want. I just want to remove it, but I don't know if it's possible. 

https://support.google.com/gemini/answer/16938321?hl=en

"Change or remove your default digital assistant app"
I don't have a None choice.  Currently my AI assistant is Google
Assistant, not Gemini, is the only choice, and cannot be changed to
none.  However, I can cripple it a bit by disabling the "Analyze
on-screen text" and "Analyze on-screen images".

In the Apps drawer, Gemini is listed.  When long-pressing it, there is
no uninstall option, just a Disable option.

I'm using a Samsung Galaxy A36 which may have a different catalog of
pre-install/bundled apps that cannot be removed versus whatever phone
you have that wasn't mentioned.

I opened the Google app.  It has a widget on my main home screen, so I
tapped the left-side icon in the search bar.  Then I tapped on my
profile icon at the top right.  Under Search Labs, it says I can turn
Gemini on.  Well, that means it is off.  Presumably you go here after
enabling Gemini to disable the Google Assistant from using Gemini.  I
never enable any of those labs (aka Experiments that Google adds and
removes whenever they want).

There are a lot of disables in the Gemini app.  I cannot uninstall it,
but I can disable it.  I'm not interested in reenabling it to see how
the disables are configured.

https://proton.me/blog/turn-off-gemini-on-android

You don't mention why you web searched already to eliminate others from
duplicating the same suggestions.  Besides "android disable gemini", you
might want to add your phone, like "android <version> disable gemini
<brand> <model>".

[toc] | [prev] | [next] | [standalone]

#156274

VanguardLH wrote:
> There are a lot of disables in the Gemini app.  I cannot uninstall it,
> but I can disable it.  I'm not interested in reenabling it to see how
> the disables are configured.

We can always uninstall any app, even a system app, even if not rooted.
 adb shell pm uninstall --user 0 com.google.android.apps.bard

[toc] | [prev] | [next] | [standalone]

#156275

Maria Sophia <mariasophia@comprehension.com> wrote:

> VanguardLH wrote:
>
>> There are a lot of disables in the Gemini app.  I cannot uninstall it,
>> but I can disable it.  I'm not interested in reenabling it to see how
>> the disables are configured.
> 
> We can always uninstall any app, even a system app, even if not rooted.
>  adb shell pm uninstall --user 0 com.google.android.apps.bard

I never recommend that procedure unless the user absolutely knows that
the absence of an app does not affect system function, or the operation
of other apps.  Disable works just as well, and has the advantage that
if an unwanted side effect then reenable is easy.  Mostly the only
advantage of uninstall is recovering storage space, like for the APK.

[toc] | [prev] | [next] | [standalone]

#156283

VanguardLH wrote:
>>> There are a lot of disables in the Gemini app.  I cannot uninstall it,
>>> but I can disable it.  I'm not interested in reenabling it to see how
>>> the disables are configured.
>> 
>> We can always uninstall any app, even a system app, even if not rooted.
>>  adb shell pm uninstall --user 0 com.google.android.apps.bard
> 
> I never recommend that procedure unless the user absolutely knows that
> the absence of an app does not affect system function, or the operation
> of other apps.  Disable works just as well, and has the advantage that
> if an unwanted side effect then reenable is easy.  Mostly the only
> advantage of uninstall is recovering storage space, like for the APK.

I know of people who are afraid of elevators. Even afraid of planes. 
Some are afraid of left turns. Most are afraid of snakes & spiders.

If it does something "unstable" to the system, then you run this next:
 adb shell cmd package install-existing --user 0 com.google.android.apps.bard

We've covered this about a thousand times on this very Android newsgroup.

[toc] | [prev] | [next] | [standalone]

#156296

Maria Sophia <mariasophia@comprehension.com> wrote:

> VanguardLH wrote:
>>>> There are a lot of disables in the Gemini app.  I cannot uninstall it,
>>>> but I can disable it.  I'm not interested in reenabling it to see how
>>>> the disables are configured.
>>> 
>>> We can always uninstall any app, even a system app, even if not rooted.
>>>  adb shell pm uninstall --user 0 com.google.android.apps.bard
>> 
>> I never recommend that procedure unless the user absolutely knows that
>> the absence of an app does not affect system function, or the operation
>> of other apps.  Disable works just as well, and has the advantage that
>> if an unwanted side effect then reenable is easy.  Mostly the only
>> advantage of uninstall is recovering storage space, like for the APK.
> 
> I know of people who are afraid of elevators. Even afraid of planes. 
> Some are afraid of left turns. Most are afraid of snakes & spiders.
> 
> If it does something "unstable" to the system, then you run this next:
>  adb shell cmd package install-existing --user 0 com.google.android.apps.bard
> 
> We've covered this about a thousand times on this very Android newsgroup.

No. This has been discussed (using ADB) only 263 times.
See, I can make up numbers, too.

[toc] | [prev] | [next] | [standalone]

#156307

VanguardLH wrote:
>> If it does something "unstable" to the system, then you run this next:
>>  adb shell cmd package install-existing --user 0 com.google.android.apps.bard
>> 
>> We've covered this about a thousand times on this very Android newsgroup.
> 
> No. This has been discussed (using ADB) only 263 times.
> See, I can make up numbers, too.

If you don't understand what a figure of speech is, then I pity you.
Seriously.

Anyway... 

The goal here is, for all of us, to give the OP the "correct" answers. 
Unfortunately, none of your responses were remotely correct, VanguardLH.

Don't blame me for that.
Blame yourself.

Don't get upset or angry with me simply because I corrected with facts.
In fact, I do commend you (and others) for trying to help the OP out.

You tried.
Seriously. You tried.

As best you could, anyway.
And that's OK.

I simply corrected you. 
That's all.

With facts.
Many times I've discussed adb, but it never sank in with people like you.

Why not? 
I don't know why not.

But every time you say crazy things like you did in this thread, it's up to
someone, me perhaps, to correct you that you *can* uninstall system apps.

Using adb.

The point is we covered this many times, that adb can easily delete apps.
Yes. Even system apps. 

And they're not necessarily fully gone either (which others pointed out).
But they're "gone enough" not to affect the user once adb deletes them.

 adb shell cmd package install-existing --user 0 com.google.android.apps.bard
-- 
Every Usenet thread should be designed as a learning experience for all.

[toc] | [prev] | [next] | [standalone]

#156279

Maria Sophia, 2026-10-05 09:48:

> VanguardLH wrote:
>> There are a lot of disables in the Gemini app.  I cannot uninstall it,
>> but I can disable it.  I'm not interested in reenabling it to see how
>> the disables are configured.
> 
> We can always uninstall any app, even a system app, even if not rooted.
>  adb shell pm uninstall --user 0 com.google.android.apps.bard

No, this just disables it. It will not be removed.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#156282

Arno Welzel wrote:
>> VanguardLH wrote:
>>> There are a lot of disables in the Gemini app.  I cannot uninstall it,
>>> but I can disable it.  I'm not interested in reenabling it to see how
>>> the disables are configured.
>> 
>> We can always uninstall any app, even a system app, even if not rooted.
>>  adb shell pm uninstall --user 0 com.google.android.apps.bard
> 
> No, this just disables it. It will not be removed.

Actually *this* disables it:
 adb shell pm disable-user --user 0 com.google.android.apps.bard

We've covered this about a thousand times on this very Android newsgroup.

[toc] | [prev] | [next] | [standalone]

#156298

Maria Sophia, 2026-10-05 17:01:

> Arno Welzel wrote:
>>> VanguardLH wrote:
>>>> There are a lot of disables in the Gemini app.  I cannot uninstall it,
>>>> but I can disable it.  I'm not interested in reenabling it to see how
>>>> the disables are configured.
>>>
>>> We can always uninstall any app, even a system app, even if not rooted.
>>>  adb shell pm uninstall --user 0 com.google.android.apps.bard
>>
>> No, this just disables it. It will not be removed.
> 
> Actually *this* disables it:
>  adb shell pm disable-user --user 0 com.google.android.apps.bard
> 
> We've covered this about a thousand times on this very Android newsgroup.

"a thousand times"? Really? So at multiple times  a week for the last 10
years?

"pm uninstall" does *not* uninstall a *system* app if it is only done
for one user.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#156309

Arno Welzel wrote:
>> We've covered this about a thousand times on this very Android newsgroup.
> 
> "a thousand times"? Really? So at multiple times  a week for the last 10
> years?
> 
> "pm uninstall" does *not* uninstall a *system* app if it is only done
> for one user.

If you don't understand what a figure of speech is, then I pity you.
The goal here is, for all of us, to give the OP the "correct" answers. 

There may be multiple correct answers, but this is certainly one of them:
 adb shell cmd package install-existing --user 0 com.google.android.apps.bard

And I've covered many times what that actually does, so I'm happy that at
least you have learned that it "might be" still in the system partition.

Note that you don't seem to understand that it's not always in the system
partition after deletion, but it is often enough that it might still be.

In fact, most of the time it is.

But I have seen cases in the past where an app classified as a system app
was actually deleted from the device, so it can happen, but it's rare.

Certainly it can happen with UPDATES to system apps, right? 
I'm sure you're aware of that as that's frequently the case, right?

So my point is if we really wish to dive into the gory details, there
aren't absolutes that we can glibly claim if we don't have experience.
-- 
Every Usenet thread should be designed as a learning experience for all.

[toc] | [prev] | [next] | [standalone]

#156336

Maria Sophia, 2026-10-06 19:38:

> Arno Welzel wrote:
>>> We've covered this about a thousand times on this very Android newsgroup.
>>
>> "a thousand times"? Really? So at multiple times  a week for the last 10
>> years?
>>
>> "pm uninstall" does *not* uninstall a *system* app if it is only done
>> for one user.
> 
> If you don't understand what a figure of speech is, then I pity you.
> The goal here is, for all of us, to give the OP the "correct" answers. 

A figure of speech does not help anyone here. The topic is not even
mentioned every month or at any regular schedule at all, so you can not
blame people for not knowing something, which is covered "a thousand times".

And yes, there are newsgroups which post certain topics as FAQ on a
regular basis. As far I am aware, the topic "How to use ADB" is *not*
covered by any FAQ posted on a regular basis here. But if I just missed
that I'm happy to see the message ID of the last submission of that.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#156343

Arno Welzel wrote:
>> If you don't understand what a figure of speech is, then I pity you.
>> The goal here is, for all of us, to give the OP the "correct" answers. 
> 
> A figure of speech does not help anyone here. The topic is not even
> mentioned every month or at any regular schedule at all, so you can not
> blame people for not knowing something, which is covered "a thousand times".
> 
> And yes, there are newsgroups which post certain topics as FAQ on a
> regular basis. As far I am aware, the topic "How to use ADB" is *not*
> covered by any FAQ posted on a regular basis here. But if I just missed
> that I'm happy to see the message ID of the last submission of that.

I just opened a thread to help others use adb, since it does everything.

 Newsgroups: comp.mobile.android
 Subject: FAQ: PSA: Tutorial: Walk-Thru etc. Random examples of using adb with Android
 Date: Thu, 8 Oct 2026 15:46:49 -0700
 Message-ID: <11a96gn$b36$1@nnrp.usenet.blueworldhosting.com>

 So that all benefit, this thread is opened to allow others to post random
 useful adb examples, where the goal is a usable list of useful examples.

[toc] | [prev] | [next] | [standalone]

#156303

On 2026-10-05 09:48, Maria Sophia wrote:
> VanguardLH wrote:
>> There are a lot of disables in the Gemini app.  I cannot uninstall it,
>> but I can disable it.  I'm not interested in reenabling it to see how
>> the disables are configured.
> 
> We can always uninstall any app, even a system app, even if not rooted.
>   adb shell pm uninstall --user 0 com.google.android.apps.bard

So, if there is a user 1, he still has the thing installed? Then the 
application is not truly erased, just somehow disabled.

-- 
Cheers,
        Carlos E.R.
        ES🇪🇸, EU🇪🇺.

[toc] | [prev] | [next] | [standalone]

#156304

Carlos E. R., 2026-10-06 12:18:

> On 2026-10-05 09:48, Maria Sophia wrote:
>> VanguardLH wrote:
>>> There are a lot of disables in the Gemini app.  I cannot uninstall it,
>>> but I can disable it.  I'm not interested in reenabling it to see how
>>> the disables are configured.
>>
>> We can always uninstall any app, even a system app, even if not rooted.
>>   adb shell pm uninstall --user 0 com.google.android.apps.bard
> 
> So, if there is a user 1, he still has the thing installed? Then the 
> application is not truly erased, just somehow disabled.

Exactly. This is why I explained, that this will not "uninstall" the app
but only disable it.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#156311

Arno Welzel wrote:
>> On 2026-10-05 09:48, Maria Sophia wrote:
>>> VanguardLH wrote:
>>>> There are a lot of disables in the Gemini app.  I cannot uninstall it,
>>>> but I can disable it.  I'm not interested in reenabling it to see how
>>>> the disables are configured.
>>>
>>> We can always uninstall any app, even a system app, even if not rooted.
>>>   adb shell pm uninstall --user 0 com.google.android.apps.bard
>> 
>> So, if there is a user 1, he still has the thing installed? Then the 
>> application is not truly erased, just somehow disabled.
> 
> Exactly. This is why I explained, that this will not "uninstall" the app
> but only disable it.

Hi Arno & Carlos,

Thanks Carlos, for asking how it works, because it's not obvious.

I've run ADB, oh, I don't know, thousands of times, and there are some
nuanced details here because uninstalling just isn't the same as disabling.

Regarding what Arno Welzel wrote:
  "This is why I explained, that this will not "uninstall" 
   the app but only disable it."

Arno, while close, is not quite technically accurate saying that.

Arno isn't allowing for the fact that Android's package manager has
several different operations for dealing with system apps. 

Despite what Arno said, the command adb shell pm uninstall --user 0 
does not disable a system app at all. It changes the package's 
installation state for that particular user.

Always looking at this from the perspective of an unrooted Android device,
for a system APK that is part of the read-only system image, Android
maintains several different pieces of package state for each user. 

So my point to Arno is that "disable", "uninstall" & "delete" are not 
interchangeable terms.

Most people on this newsgroup can't comprehend these details below, 
but I invest the energy into you because I know you can (as can Andy).

For example:
 1. adb shell pm disable-user --user 0 com.google.android.apps.bard
    This changes the enabled/disabled state for user 0. 
    The APK remains in the system image, and the package remains
    installed for that user.

 2. adb shell pm uninstall --user 0 com.google.android.apps.bard
    This marks the package as uninstalled for user 0 and removes
    the package from that user's installed packages. 
    It does not delete the APK from the read-only system image.

The system APK is therefore still present on the device.
Therefore, it can be made installed for user 0 again with:

 3. adb shell cmd package install-existing --user 0 com.google.android.apps.bard
    This does not download or copy an APK. 
    It makes an existing system package installed for that user again.

A package can also be suspended (what various tools call "freezing"
an app), for example:

 4. adb shell cmd package suspend --user 0 com.google.android.apps.bard
    Suspension is yet another package state.
    The package remains installed and its APK remains in the system image, 
    but Android prevents the user from normally using it while suspended.

Note if there is a user 1, that user 1 can have a completely different 
package state from user 0. User 0 can have the system package uninstalled
while user 1 still has it installed and enabled. 

The point is the APK itself is shared but per-user package state is not.

Then there is the concept of actually deleting the system APK.

Without root, an ordinary ADB shell/Package Manager operation cannot
delete an APK that is genuinely part of the read-only system image.
[Note: Some may be "marked" as system apps, but they're not really.]
[Note: Many system apps have user updates that can be uninstalled.]

While adb pm uninstall --user 0 changes the package state for that
user, it does not erase /system, /product, /system_ext, etc.

This is also why install-existing works: it isn't reinstalling the APK.
It is telling Package Manager to use the already-existing system APK for
that user again.

Since I use Shizuku a lot, it's important to add what Shizuku does.
Shizuku can give an app access to many of the same privileged 
shell/Package Manager operations without root, which is useful.

For example, I just started Shizuku for this post:
 adb shell sh /storage/emulated/0/Android/data/moe.shizuku.privileged.api/start.sh
 info: start.sh begin
 info: attempt to copy starter from /storage/emulated/0/Android/data/moe.shizuku.privileged.api/starter to /data/local/tmp/shizuku_starter
 info: exec /data/local/tmp/shizuku_starter
 info: starter begin
 info: killing old process...
 info: apk path is /data/app/~~j2Bfj74f4DUXxNA5r8nvlQ==/moe.shizuku.privileged.api-EfgdS0yVAmbHZDgZAOOXtg==/base.apk
 info: starting server...
 info: shizuku_starter exit with 0

There's also Termux/Remote-interactive-shell (rish), localadb (ladb)
and ShizuShell, all of which I have discussed here in the past.

And, there are ways to start Shizuku using adb wireless debugging too.
 Starting with wireless adb...
 info: start.sh begin
 info: attempt to copy starter from /storage/emulated/0/Android/data/moe.shizuku.privileged.api/starter to /data/local/tmp/shizuku_starter
 info: exec /data/local/tmp/shizuku_starter
 info: starter begin
 info: killing old process...
 info: killed 8675 (shizuku_server)
 info: apk path is /data/app/~~j2Bfj74f4DUXxNA5r8nvlQ==/moe.shizuku.privileged.api-EfgdS0yVAmbHZDgZAOOXtg==/base.apk
 info: starting server...
 info: shizuku_starter exit with 0
 Waiting for service...
 Service started, this window will be automatically closed in 3 seconds

With Shizuku, dozens of programs inherit extra shell privileges.
For example, I have, oh, let me look, OK, 34 apps with Shizuku.
 Owlfiles, Total Commander, Obtainium, Warden, ZArchiver, X-plore,
 Insular, LSPatch, Package Manager, Aurora Store, LogFox, 
 Better Internet Tiles, SAI, Fluffy, App Ops, Settings Database Editor,
 Button Mapper, FV File Explorer, MiXplorer, Droid-ify, ShizuShell,
 Cx File Explorer, Key Mapper, DevCheck, Universal Installer, Canta,
 Ultimate File Manager Pro and 11 of them are in "- Island" too.
 Note: I have no idea why that particular order is presented.

But while a Shizuku-based tool can disable, suspend/freeze or
uninstall a system package for a user, it does not give that app
root privileges or make a genuinely read-only system partition writeable.

So "it doesn't truly uninstall the app" is a reasonable shorthand if
"uninstall" means physically deleting the APK. But saying that
pm uninstall --user 0 "only disables" it is technically wrong because
disabling, suspending and per-user uninstalling are separate Package
Manager states with different semantics.

Overall, this clarification is a good technical review for us to know!
-- 
Every Usenet post should strive to show additional value that wasn't there.

[toc] | [prev] | [next] | [standalone]

#156316

On 2026-10-06 20:31, Maria Sophia wrote:
> Arno Welzel wrote:
>>> On 2026-10-05 09:48, Maria Sophia wrote:
>>>> VanguardLH wrote:
>>>>> There are a lot of disables in the Gemini app.  I cannot uninstall it,
>>>>> but I can disable it.  I'm not interested in reenabling it to see how
>>>>> the disables are configured.
>>>>
>>>> We can always uninstall any app, even a system app, even if not rooted.
>>>>    adb shell pm uninstall --user 0 com.google.android.apps.bard
>>>
>>> So, if there is a user 1, he still has the thing installed? Then the
>>> application is not truly erased, just somehow disabled.
>>
>> Exactly. This is why I explained, that this will not "uninstall" the app
>> but only disable it.
> 
> Hi Arno & Carlos,
> 
> Thanks Carlos, for asking how it works, because it's not obvious.
> 
> I've run ADB, oh, I don't know, thousands of times, and there are some
> nuanced details here because uninstalling just isn't the same as disabling.
> 
> Regarding what Arno Welzel wrote:
>    "This is why I explained, that this will not "uninstall"
>     the app but only disable it."
> 
> Arno, while close, is not quite technically accurate saying that.
> 
> Arno isn't allowing for the fact that Android's package manager has
> several different operations for dealing with system apps.
> 
> Despite what Arno said, the command adb shell pm uninstall --user 0
> does not disable a system app at all. It changes the package's
> installation state for that particular user.
> 
> Always looking at this from the perspective of an unrooted Android device,
> for a system APK that is part of the read-only system image, Android
> maintains several different pieces of package state for each user.
> 
> So my point to Arno is that "disable", "uninstall" & "delete" are not
> interchangeable terms.
> 
> Most people on this newsgroup can't comprehend these details below,
> but I invest the energy into you because I know you can (as can Andy).
> 
> For example:
>   1. adb shell pm disable-user --user 0 com.google.android.apps.bard
>      This changes the enabled/disabled state for user 0.
>      The APK remains in the system image, and the package remains
>      installed for that user.
> 
>   2. adb shell pm uninstall --user 0 com.google.android.apps.bard
>      This marks the package as uninstalled for user 0 and removes
>      the package from that user's installed packages.
>      It does not delete the APK from the read-only system image.
> 
> The system APK is therefore still present on the device.
> Therefore, it can be made installed for user 0 again with:
> 
>   3. adb shell cmd package install-existing --user 0 com.google.android.apps.bard
>      This does not download or copy an APK.
>      It makes an existing system package installed for that user again.
> 
> A package can also be suspended (what various tools call "freezing"
> an app), for example:
> 
>   4. adb shell cmd package suspend --user 0 com.google.android.apps.bard
>      Suspension is yet another package state.
>      The package remains installed and its APK remains in the system image,
>      but Android prevents the user from normally using it while suspended.
> 
> Note if there is a user 1, that user 1 can have a completely different
> package state from user 0. User 0 can have the system package uninstalled
> while user 1 still has it installed and enabled.
> 
> The point is the APK itself is shared but per-user package state is not.
> 
> Then there is the concept of actually deleting the system APK.
> 
> Without root, an ordinary ADB shell/Package Manager operation cannot
> delete an APK that is genuinely part of the read-only system image.
> [Note: Some may be "marked" as system apps, but they're not really.]
> [Note: Many system apps have user updates that can be uninstalled.]
> 
> While adb pm uninstall --user 0 changes the package state for that
> user, it does not erase /system, /product, /system_ext, etc.
> 
> This is also why install-existing works: it isn't reinstalling the APK.
> It is telling Package Manager to use the already-existing system APK for
> that user again.

Ok, so the package remains in the filesystem, it is not removed. To do 
so needs being root. It is just marked as uninstalled or disabled for 
user 0. Fine.

Then, what is the advantage of this system over the GUI method of 
disabling an app? The effects are the same, AFAIK.

Is there a difference with updates? A system update can activate 
disabled system apps. One has to remember to deactivate them once more. 
Is this the same with adb?


-- 
Cheers,
        Carlos E.R.
        ES🇪🇸, EU🇪🇺.

[toc] | [prev] | [next] | [standalone]

#156320

Carlos E. R. wrote:
> Ok, so the package remains in the filesystem, it is not removed. To do 
> so needs being root. It is just marked as uninstalled or disabled for 
> user 0. Fine.
> 
> Then, what is the advantage of this system over the GUI method of 
> disabling an app? The effects are the same, AFAIK.
> 
> Is there a difference with updates? A system update can activate 
> disabled system apps. One has to remember to deactivate them once more. 
> Is this the same with adb?

Hi Carlos,

It's good that you're asking questions, as these questions I would ask too.

You are correct that using adb to (let's use loose terms) "get rid of" the
effects of an app (which, in this case, is com.google.android.apps.bard) is
not different, in effect, from simply doing the same thing in the GUI.... 

                 *if the GUI allows it*

To Carlos' point, adb shell allows bypassing GUI restrictions, where many
system (bloatware) apps have the Disable/Uninstall" buttons grayed out.

Also we have to consider storage and cache reclaiming, which we can't
always control for system apps using just the GUI, as adb allows granular
control that may not be available in the GUI.

An example we ran into long ago is that people "think" they know which apps
are accessing their contacts, but if they use only the GUI, they do not.

Also, adb allows precise targeting of specific users (--user 0, --user 10,
etc.) & multi-profile environments like Island or Shelter (Work Profiles).

However, Carlos is right that OTA and system updates can re-enable system
apps that we thought were "gone" so I won't dismiss the possibility that it
can likely happen, particularly after major OS updates perhaps (or, of
course, after a complete factory reset).

In addition, adb allows if/then/else scripting, which isn't in a GUI.
 a. disable -> changes enabled state
 b. uninstall --user -> removes the package from that user's set
 c. clear -> removes that user's app data
 d. suspend -> prevents normal use while leaving it installed
 e. install-existing -> restores an existing system package for that use	r

In addition, adb is easily reproducible. For example, if I factory reset, I
can re-run my saved adb commands which can re-establish a previous state.

But overall, my answer to Carlos' reasonable question is simply that ADB
exposes operations that the Android GUI may not expose, and lets us perform
them precisely, repeatedly, and on a specified user/profile.
-- 
Every post to Usenet should strive to add value or it shouldn't be posted.

[toc] | [prev] | [next] | [standalone]

#156322

On 2026-10-06 21:28, Maria Sophia wrote:
> Carlos E. R. wrote:
>> Ok, so the package remains in the filesystem, it is not removed. To do
>> so needs being root. It is just marked as uninstalled or disabled for
>> user 0. Fine.
>>
>> Then, what is the advantage of this system over the GUI method of
>> disabling an app? The effects are the same, AFAIK.
>>
>> Is there a difference with updates? A system update can activate
>> disabled system apps. One has to remember to deactivate them once more.
>> Is this the same with adb?
> 
> Hi Carlos,
> 
> It's good that you're asking questions, as these questions I would ask too.
> 
> You are correct that using adb to (let's use loose terms) "get rid of" the
> effects of an app (which, in this case, is com.google.android.apps.bard) is
> not different, in effect, from simply doing the same thing in the GUI....
> 
>                   *if the GUI allows it*
> 
> To Carlos' point, adb shell allows bypassing GUI restrictions, where many
> system (bloatware) apps have the Disable/Uninstall" buttons grayed out.

Ah, good point.

> 
> Also we have to consider storage and cache reclaiming, which we can't
> always control for system apps using just the GUI, as adb allows granular
> control that may not be available in the GUI.
> 
> An example we ran into long ago is that people "think" they know which apps
> are accessing their contacts, but if they use only the GUI, they do not.
> 
> Also, adb allows precise targeting of specific users (--user 0, --user 10,
> etc.) & multi-profile environments like Island or Shelter (Work Profiles).
> 
> However, Carlos is right that OTA and system updates can re-enable system
> apps that we thought were "gone" so I won't dismiss the possibility that it
> can likely happen, particularly after major OS updates perhaps (or, of
> course, after a complete factory reset).
> 
> In addition, adb allows if/then/else scripting, which isn't in a GUI.
>   a. disable -> changes enabled state
>   b. uninstall --user -> removes the package from that user's set
>   c. clear -> removes that user's app data
>   d. suspend -> prevents normal use while leaving it installed
>   e. install-existing -> restores an existing system package for that use	r
> 
> In addition, adb is easily reproducible. For example, if I factory reset, I
> can re-run my saved adb commands which can re-establish a previous state.
> 
> But overall, my answer to Carlos' reasonable question is simply that ADB
> exposes operations that the Android GUI may not expose, and lets us perform
> them precisely, repeatedly, and on a specified user/profile.

Certainly. Just that not everybody is happy with such a powerful tool.

-- 
Cheers,
        Carlos E.R.
        ES🇪🇸, EU🇪🇺.

[toc] | [prev] | [next] | [standalone]

#156326

Carlos E. R. wrote:
>> But overall, my answer to Carlos' reasonable question is simply that ADB
>> exposes operations that the Android GUI may not expose, and lets us perform
>> them precisely, repeatedly, and on a specified user/profile.
> 
> Certainly. Just that not everybody is happy with such a powerful tool.

Hi Carlos,

I appreciate your questions, 'cuz Arno, for example, only complained that I 
used a figure of speech (thousands of times) that he objected to me using.

Anyway, adb is super powerful, and very useful, as I use it all day, every 
day. Just moments ago I had to use adb to fix my wife's PulseSMS which 
upgraded on Google Play to the latest version (which has advertisements!).
 adb install -d -r -i not.com.android.vending PulseSMS5.4.6.2816.apk

Normally that works because it does the following:
 -d means allow downgrades
 -r means replace w/o wiping out the data
 -i means say it's not coming from the Google Play Store 

Where adb allows me to check this information to make sure it stuck.
 adb shell dumpsys package xyz.klinker.messenger | findstr installerPackageName
  => installerPackageName=not.com.android.vending

But, apparently due to mismatches in versions, the downgrade kept crashing.
So I checked what the versions were using adb which is very useful to do.
 adb shell dumpsys package xyz.klinker.messenger | findstr "versionName versionCode"
  => versionCode=2816 minSdk=21 targetSdk=30
  => versionName=5.4.6.2816

But I had to check what SDK version her phone was set to (which is SDK 33)
 adb shell getprop ro.build.version.sdk
  => 33

And then I had to check which version the APK was set to NOT run on.
 aapt dump badging pulsesms_5.4.11.2831.apk | findstr /R "sdkVersion versionName versionCode"
  => package: name='xyz.klinker.messenger' versionCode='2831' 
  => versionName='5.4.11.2831' compileSdkVersion='30' compileSdkVersionCodename='11'
  => sdkVersion:'21'

It shouldn't have crashed, but it's probably a database schema mismatch.
Even though the database "appears" empty, adb shows me 26K messages.
 adb shell content query --uri content://sms/
Which is so huge, that I just got a quick summary of all 26K messages.
 adb shell content query --uri content://sms/ --projection _id
  => ... over twenty six thousand rows... 
  => ... ending with... 
  => Row: 26692 _id=34
  => Row: 26693 _id=33
  => Row: 26694 _id=32
  => Row: 26695 _id=31

So even though her PulseSMS downgrade can't read the database, it's there.
So, let's back up her pulseSMS sqlite database before I do anything else.
 adb backup -apk -shared -f pulsesms.ab xyz.klinker.messenger
 On the phone, it says:
 A full backup of all data to a connected desktop computer has been requested.
 Do you want to allow this to happen?
 If you wish to encrypt the full backup, enter a password below.
 => WARNING: adb backup is deprecated and may be removed in a future release
 => Now unlock your device and confirm the backup operation...
 On the phone, I tap the button "Back up my data"
 That takes a while, but the result should be all data allowed to be backed up.
  pulsesms.ab
 
It's still backing up but my point is that adb does everything we need!
-- 
On Usenet, kind-hearted experts combine their experiences to help others.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.mobile.android

csiph-web