Following up on this post in a thread from Stan I don't want to hijack
*Google nag to turn Discover on*
<https://www.novabbs.com/computers/article-flat.php?id=57854&group=comp.mobile.android#57854>

In that thread, I looked up what "Google Discover" was, since I had never experienced it in all my years of using non-rooted Android phones. It
turned out I had disabled it long ago for "user 0" but not for "user 11".

I didn't even know I had a "user 0" and a "user 11" on my phone.
Did you know that?

Anyway, this post is written so that anyone can cut & paste the commands
below to determine if you (or the other users on your phone), have it.

If you have it, you can wipe it out.
It's what I do to all the google packages (that don't break the system).

It's important to note that 'Google Discover' is inside this package.
<com.google.android.googlequicksearchbox>

I have that package on my Android 13 Galaxy so why don't I see "Discover"?

adb shell pm list packages com.google.android.googlequicksearchbox

(this lists it)

Luckily for me, it's been long ago "disabled" by me (probably en masse):

adb shell pm list packages -d com.google.android.googlequicksearchbox

(this lists it)

I looked to see if it was "stopped" also (in addition to disabled).

adb shell "dumpsys package com.google.android.googlequicksearchbox | grep stopped="

The output indicated that the package wasn't installed for "user 0" but it
was installed (& working) for "user 11", so I needed to figure who is who.

adb shell am get-current-user

This reported that I'm user 0 when running adb

Digging deeper, since I have no accounts set up on my phone, apparently I'm user 0 & apparently my "work profile" is "user 11" (which I didn't know).

So for the work profile, the Discover functionality exists, but not for the main profile of mine. (I don't have any "accounts" set up on my phone.)

I'll post a followup that starts with all that in mind, but that's a
summary that I brought over from the aforementioned thread, for starters.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 21 Mar 2025 04:50:31 -0000 (UTC), Marion wrote :

If you've been following, this is a core feature of Android I'm hitting.
a. The system partition contains the APK
b. So that's why I could re-install it into the user 0 data partition
c. But Android won't let me re-install it into the user 11 data partition

Given you can uninstall and re-install system packages on any non-rooted Android, but you can only do so for user 0 and not for the work profile user 11, there's a trick to re-install this non-debuggable system package
for the work profile user 11 which takes advantage of how Android works.

For most (all?) system packages, Android never actually deleted them!

adb shell pm path com.google.android.googlequicksearchbox

package:/product/priv-app/Velvet/Velvet.apk

Huh? Velvet? It turns out "Velvet" is a Google internal codename.

Now copy that system APK to the computer:

adb pull /product/priv-app/Velvet/Velvet.apk .\velvet.apk

/product/priv-app/Velvet/Vel... (276644880 bytes in 8.645s)

Now install that APK from the system partition to the work profile.

adb install --user 11 .\velvet.apk

Performing Streamed Install
Success

Now check if it's really installed for the work profile user 11.

adb shell pm list packages --user 11 | findstr googlequicksearchbox

(it's there!)

In summary, this shows empirically how Android handles system packages.

1. Any non-root user can still remove (most) system packages
2. But, they are not deleted. They're just removed for the user
3. They stay in the system partition (since they're system packages)

So...
A. You can easily re-install these deleted system packages for the user
B. But, you have to extract them first, to re-install for the work profile

Who knew?
Not me.
Now I do!

Of course, I deleted it since I don't ever want to see Google Discover!

adb shell pm uninstall --user 0 com.google.android.googlequicksearchbox

Success

adb shell pm uninstall --user 11 com.google.android.googlequicksearchbox

Success

Double checking, they're gone.

adb shell pm list packages --user 0 com.google.android.googlequicksearchbox

(nothing is reported)

adb shell pm list packages --user 11 com.google.android.googlequicksearchbox

(nothing is reported)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 21 Mar 2025 04:06:54 -0000 (UTC), Marion wrote :

So for the work profile, the Discover functionality exists, but not for the main profile of mine. (I don't have any "accounts" set up on my phone.)

The first thing I have to do is figure out how many "users" exist.

adb shell pm list users

Users:
UserInfo{0:Owner:c13} running
UserInfo{11: Island :10b0}

List if the package is installed for each of those userids, 0 & 11.

adb shell pm list packages --user 0 com.google.android.googlequicksearchbox

(the package does NOT show up, which means it's not installed)

adb shell pm list packages --user 11 com.google.android.googlequicksearchbox

(the package does show up, which means it is installed)

To remove it for user 11.

adb shell pm uninstall --user 11 com.google.android.googlequicksearchbox

Success

To check that it's gone for user 11.

adb shell pm list packages --user 11 com.google.android.googlequicksearchbox

(the package does NOT show up, which means it's not installed)

As a test, I tried re-installing it (from the system partition).

adb shell cmd package install-existing com.google.android.googlequicksearchbox

Package com.google.android.googlequicksearchbox installed for user: 0

Notice it worked to re-install the app for user 0 but not for user 11!
To install it back for user 11 is not simple, it turns out.

First, check that it's not there:

adb shell pm list packages --user 11 | findstr googlequicksearchbox

(nothing was reported)

The re-install for user 11 fails as the system package isn't debuggable.

adb shell "run-as com.google.android.googlequicksearchbox cmd package install-existing com.google.android.googlequicksearchbox"

run-as: package not debuggable: com.google.android.googlequicksearchbox

Isn't that interesting!
This system package isn't set to debuggable in its manifest.
That's a security measure.

If you've been following, this is a core feature of Android I'm hitting.
a. The system partition contains the APK
b. So that's why I could re-install it into the user 0 data partition
c. But Android won't let me re-install it into the user 11 data partition

Android's security model enforces strict isolation between user profiles.
This prevents apps in one profile from accessing or modifying data in
another profile.

But there's a trick!
I'll write up the trick next, as it's a fundamental way Android works.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 21/03/2025 04:06, Marion wrote:

In that thread, I looked up what "Google Discover" was, since I had never experienced it in all my years of using non-rooted Android phones. It
turned out I had disabled it long ago for "user 0" but not for "user 11".

I didn't even know I had a "user 0" and a "user 11" on my phone.
Did you know that?

No, but then I know very little about Android other than a bit of
searching reveals.

It appears that "users" in Android seem to have been around for years.
See here, referring to "user 10" and "user 11": <https://stackoverflow.com/questions/19272015/android-user-profile-questions> By the way, "user 10" is still around as a (the?) "work profile". Why
user 10 /and/ user 11? I see from <https://support.google.com/work/android/answer/6191949?hl=en#zippy=%2Cdoes-my-device-have-a-work-profile>
that a work profile applies to Android 5 and later. Were work profiles
for commercial organisations that had a single mobile phone for multiple
users?

As you have a pretty good knowledge of Android, how has this remained
hidden from you? And, for that matter, "Velvet" - see your post
downthread! According to this old thread <https://xdaforums.com/t/q-what-is-velvet-apk.2372735/> there is a
difference of opinion as to what Velvet.apk is - Google's "search app"-
or something else. If it's really 277MB in size now as you mentioned, it
must be doing rather a lot of "something else"... But what?
Unfortunately the word "velvet" appears in many different things related
to Android and/or Google, and I couldn't tie down the search terms
enough to turn up anything other than that xdaforums page. :-(

--
Jeff

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Jeff Layman wrote:

Marion wrote:

I didn't even know I had a "user 0" and a "user 11" on my phone.
Did you know that?

No, but then I know very little about Android other than a bit of
searching reveals.

It appears that "users" in Android seem to have been around for years.

AFAIK every app installed gets its own filesystem, with its own user as
the owner of the filesystem and processes, user 0 presumably being root.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 21 Mar 2025 09:07:52 +0000, Andy Burns wrote :

It appears that "users" in Android seem to have been around for years.

AFAIK every app installed gets its own filesystem, with its own user as
the owner of the filesystem and processes, user 0 presumably being root.

Hi Andy,

You know Android better'n I do. I was kind of sort of aware that every app
gets its own filesystem (although I might not have stated it that way).

The way I'd put it is each app gets its own dedicated directory within the /data/data/ partition and each app gets assigned a unique user id (UID).

Apps therefore run under their own unique UIDs, which are different from
both user 0 and the Linux root user (UID 0) which I had to look up to be
sure.

To clarify, apparently "UID 0" is root while "user 0" is the "Owner" of the device (which, by definition, is the first user created on the device).

This command reports the Android user (or Owner) of the device.

adb shell am get-current-user

0

adb shell pm list users

Users:
UserInfo{0:Owner:c13} running
UserInfo{11: Island :10b0}

UserInfo{0:Owner:c13} is apparently the primary user profile as "Owner" is apparently the standard name for the main user on an Android device where
"c13" indicates the user is based on Android 13.

UserInfo{11: Island :10b0} indicates a work profile created by Insular
where the name "Island" is what Insular labels the created work profile. We
can ignore that profile for this discussion.

So we have to be careful how we state "User 0" which is different from "UID
0", one being the owner of a non-rooted device, and the other being root.

To look at the UID of any given package, let's take aurora store.

adb shell pm list packages | findstr aurora

package:com.aurora.store

adb shell dumpsys package com.aurora.store | findstr userId

userId=10803

This apparently means that all files and processes associated with the
Aurora Store are owned by UID 10803, which isolates them from other apps.

In summary, your sentence I'm responding to confused me, but it was
completely correct up until you mentioned root. I can't verify that part.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/21/2025 2:01 AM, Jeff Layman wrote:

Were work profiles for commercial organisations that had a single mobile phone for multiple
users?

Not quite. Work profiles are for BYOD (bring your own device), where a
worker wants to have access to their employer's network and apps on
their personal phone, rather than carrying two separate devices -- one
for work and one for personal use.

In general, IT staff can set limitations on what apps are available in
the work profile, can prevent files from being shared from the work
profile, can prevent copy-and-paste from the work profile, and can
remotely wipe the work profile completely if the employee leaves or the
phone is lost.

Regards,

-David

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)