My Samsung Galaxy A32-5G (Android 13) APEX listing shows a full set of
Google Mainline modules, but my Google Play system update date is stuck at >June 1, 2023 when viewed by System > About phone > Software information
If you have a Samsung, what is your Google Play system update date?
Are all Samsung's frozen? Or just mine?
I ran Termux & looked at the /system/apex directory...
$ cd /system
/system $ cd apex
/system/apex $ dir
com.android.apex.cts.shim.apex
com.android.btservices.apex
com.android.i18n.apex
com.android.runtime.apex
com.android.uwb.capex
com.android.vndk.current.apex
com.android.wifi.capex
com.google.android.adbd_compressed.apex >com.google.android.adservices_compressed.apex >com.google.android.appsearch_compressed.apex >com.google.android.art_compressed.apex >com.google.android.cellbroadcast_compressed.apex >com.google.android.conscrypt_compressed.apex >com.google.android.extservices_compressed.apex >com.google.android.ipsec_compressed.apex >com.google.android.media.swcodec_compressed.apex >com.google.android.media_compressed.apex >com.google.android.mediaprovider_compressed.apex >com.google.android.neuralnetworks_compressed.apex >com.google.android.ondevicepersonalization_compressed.apex >com.google.android.os.statsd_compressed.apex >com.google.android.permission_compressed.apex >com.google.android.resolv_compressed.apex >com.google.android.scheduling_compressed.apex >com.google.android.sdkext_compressed.apex >com.google.android.tethering_compressed.apex
com.google.android.tzdata4.apex
com.google.mainline.primary.libs.apex
com.samsung.android.ipm.apex
com.samsung.android.shell.apex
com.samsung.android.spqr.apex
/system/apex $
Apparently these are the baseline Android components: >com.android.btservices.apex - Bluetooth stack
com.android.i18n.apex - internationalization libraries >com.android.runtime.apex - ART runtime (Dalvik/ART) >com.android.vndk.current.apex - vendor compatibility libraries >com.android.wifi.capex - Wi-Fi stack
com.android.uwb.capex - ultra-wideband stack (if hardware present) >com.android.apex.cts.shim.apex - compatibility shim
Apparently those are not updated through Google Play on Samsung.
They update only through Samsung firmware OTAs
Apparently these are Google Mainline APEX modules >com.google.android.adbd_compressed.apex - ADB daemon >com.google.android.adservices_compressed.apex - Privacy Sandbox ad services >com.google.android.appsearch_compressed.apex - on-device search index >com.google.android.art_compressed.apex - ART runtime (Google version) >com.google.android.cellbroadcast_compressed.apex - emergency alerts >com.google.android.conscrypt_compressed.apex - TLS/SSL crypto provider >com.google.android.extservices_compressed.apex - text classification /
smart actions
com.google.android.ipsec_compressed.apex - VPN/IPsec stack >com.google.android.media_compressed.apex - media framework >com.google.android.media.swcodec_compressed.apex - software codecs >com.google.android.mediaprovider_compressed.apex - media indexing >com.google.android.neuralnetworks_compressed.apex - NNAPI >com.google.android.ondevicepersonalization_compressed.apex - ODP >personalization engine
com.google.android.os.statsd_compressed.apex - system telemetry >com.google.android.permission_compressed.apex - permission enforcement >com.google.android.resolv_compressed.apex - DNS resolver >com.google.android.scheduling_compressed.apex - job scheduler >com.google.android.sdkext_compressed.apex - SDK extensions >com.google.android.tethering_compressed.apex - tethering stack >com.google.android.tzdata4.apex - time zone data >com.google.mainline.primary.libs.apex - shared libraries for Mainline
Apparently these are Samsung-specific system components: >com.samsung.android.ipm.apex - Samsung Intelligent Performance Manager >com.samsung.android.shell.apex - Samsung shell environment >com.samsung.android.spqr.apex - Samsung security/privilege framework
These are apparently unique to Samsung and replace some Google behaviors
In summary, apparently the APEX modules exist in /system/apex/.
a. They load normally at boot.
b. But they never update through Google Play.
Apparently, they only update when Samsung pushes a full firmware OTA.
Are my APEX modules frozen because Samsung freezes them, or because I >disabled something? What matters is what other Samsungs show.
My Samsung Galaxy A32-5G (Android 13) APEX listing shows a full set of
Google Mainline modules, but my Google Play system update date is stuck at June 1, 2023 when viewed by System > About phone > Software information
If you have a Samsung, what is your Google Play system update date? Are
all Samsung's frozen? Or just mine?
On 3/9/2026 1:45 AM, Maria Sophia wrote:
My Samsung Galaxy A32-5G (Android 13) APEX listing shows a full set of
Google Mainline modules, but my Google Play system update date is stuck at >> June 1, 2023 when viewed by System > About phone > Software information
If you have a Samsung, what is your Google Play system update date? Are
all Samsung's frozen? Or just mine?
I'm on February 1, 2026 on both my S23 phone & A9+ tablet.
I've had to do manual Play System updates for a while -- to do so, click
on the words "Google Play system update" on the screen displaying the
Play System version.
-David
AJL wrote:
I'm on February 1, 2026 on both my S23 phone & A9+ tablet.
I've had to do manual Play System updates for a while -- to do so, click >>>on the words "Google Play system update" on the screen displaying the >>>Play System version.
Interesting. On my Samsung tablet I didn't realize that was a button cause >> it had the date info displayed on it. When I pushed it, it updated from
November 1, 2025 to February 1, 2026. Wonder why it's not automatic? Weird. >> Thanks.
Thanks for that information from AJL & David Oseas as it shows that the >"Google Play system update" is updating on both your Samsung devices.
On my Android 13 Samsung Galaxy A32-5G, longpressing on the "Google Play >system update" in the Settings > About phone > Software information doesn't >do anything but of course, my April 2021 SM-A326U phone is out of support.
Android Security Patch Level = February 1, 2025
But wait!
Don't *all* Android 10+ phones (get monthly) Project Mainline updates?
What's the date on your /system/apex files?
Mine appear to be frozen in time...
Termux> ls -l /system/apex
com.google.android.adbd_compressed.apex Dec 31,2008
com.google.android.adservices_compressed.apex Dec 31,2008
com.google.android.appsearch_compressed.apex Dec 31,2008
etc.
The reason I ask the question is that it appears that my Samsung Galaxy >A32-5G (which is no longer fully supported) is NOT getting the Project >Mainline APEX (Android Pony Express) modules that I thought *all* Android
10+ phones are getting. They exist for sure, but they're not ever updated.
The whole point of Project Mainline was to improve security-patch speed and >reduce reliance on OEM full-system updates, yet, mine isn't updating.
It could be something I did though, since everyone else's Google Play >services update (so far) is newer than mine, as mine has never updated.
Can others, especially AJL who just updated today, check their dates?
Termux> ls -l /system/apex
Or, if you don't have termux:
adb shell ls -l /system/apex
The reason I ask is I'm assuming if Mainline is working, then the Google
APEX modules will have recent timestamps (most likely with date stamps >matching the Google Play system update date).
My Samsung Galaxy A32-5G (Android 13) APEX listing shows a full set of
Google Mainline modules, but my Google Play system update date is stuck at June 1, 2023 when viewed by System > About phone > Software information
If you have a Samsung, what is your Google Play system update date?
Are all Samsung's frozen? Or just mine?
AJL wrote:
Well... I went and pushed that magic button on my 6 year old Samsung Galaxy >> S10+ (Android 12) and darned if it didn't also update to February 1, 2026. >> Again it seems weird that the "security" Play System update (listed under >> Biomentrics and Security on this phone) didn't automatically update being >> that it was obviously available...
Thanks AJL for confirming that the magic button is working on an Android 12 >S10+, since what matters most for this thread isn't my own phone (as I
could have broken something) but what happens on everyone else's phone.
I'm trying to prove whether or not Project Mainline is working.
I'm sure it is.
But I'd like to see proof that Mainline is updating APEX modules monthly.
And I think you showed good evidence, even if it may not be proof, per se.
In a test I just ran (in response to Andy's post), I "think" my Galaxy >doesn't expose the /apex mount point (only the /system/apex copy), so it's >hard for me to tell what the actual versions are on my APEX modules.
Only the Pixels know for sure. :)
Just to be clear, I don't really care about my phone, (as it's very likely
I broke something long ago), but what I do care very much about is how to >tell EXACTLY if Project Mainline is updating monthly everyone's modules.
So far, it seems that, (by all account?), the "Google Play system update" >button doesn't work automagically, but maybe a reboot would do it too?
AJL wrote:
So far, it seems that, (by all account?), the "Google Play system update" >>>button doesn't work automagically, but maybe a reboot would do it too?
Dunno. In its youth IIRC Samsung occasionally required my Galaxy S10+ to
update and reboot. However in recent times it hasn't requested such. I'm
Probablly derelect in not just doing it periodically myself. Resolution:
I'll start. This Chromebook I'm posting with is 3 years old now and it
still bugs me when an update is needed. Dunno about the Play System though >> as it's not listed in settings even though the Chromebook runs Android (I'm >> posting with an Android app). But then from what I read Chromebooks as I
know them are on their way out and that nasty OS Android will be taking
them over...
Interesting that folks have to "push the button" to get the Google Play >system update to update, as we'd all think it should be automatic.
Even worse if you have to reboot in order to get it to be automatic.
The whole point of my action was to prove, for sure, that Project Mainline >was updating my phone monthly (and yours, and everyone else's phone too!).
However, in one way, my system is the wrong one to test because it's highly >modified, although, in another way, it's the perfect system to test 'cuz I >don't have the google play store app, nor do I have a google account set up >on the phone, so if my phone is updating monthly, then yours is too! :)
Since I can't read what's in /apex (apparently Pixels can), I can only look >at my "staging" area in /system/apex, but those files have very old dates,
so that tells me almost nothing of value on my Samsung device.
As a compromise, I started looking at the date for the google play system >update, which is when I realized mine is really off kilter compared to >everyone else's. Then Jeff pointed out that the google Play system update >date is the date of only a single file - which - gets even more complicated >since it's a different file on each device apparently. Sheesh. So complex.
The date shown in Settings > Security > Google Play system update
apparently comes from the timestamp of the "APEX session" responsible for
the last successfully applied Mainline module.
Hence, it is not the newest module on the device because it's the one that >last triggered a system-level session commit. Apparently that means the >displayed date corresponds to one specific APEX module, but which one
varies by device, OEM, and update sequence. OMG. Can't they make it easy?
Apparently, the date is tied to the last module that required a reboot to >finalize, because only those modules create a system-level "session" that >updates the global timestamp of the Google Play system update button.
These are the modules that most often require a reboot, apparently:
com.android.runtime.apex - ART (Android Runtime)
com.android.conscrypt.apex - TLS/SSL security provider
com.android.media.apex - media codecs
com.android.permission.apex - permission controller
com.android.adbd.apex - ADB daemon
com.android.os.statsd.apex - stats daemon
But wait. It gets worse.
On Pixels, apparently the date often corresponds to ART or Conscrypt.
But on Samsung devices, it is apparently Conscrypt or Permission because >Samsung blocks or delays ART updates after major One UI releases.
At least there is a Venn overlap with com.android.conscrypt.apex
Apparently, pressing the Google Play system update button works because it >triggers Android's Mainline update client to run a forced check-and-apply >cycle for modular APEX/APK components.
Apparently, pressing that button contacts Google's update servers and asks >for any pending APEX or APK-based Mainline modules. It then attempts to >install any modules that it downloaded or which were previously downloaded >but no "commit" step occurred.
What's that commit step?
Hell if I know, but it seems to be one of two actions for sure:
1. If the user reboots, or,
2. If the user manually triggers that update.
In summary, apparently, the reason people are seeing updates happen when
they press the Google Play system update button is that there are two steps
1. Download
2. Apply (or reboot)
Hence, the "Google Play system update" date is not the date of all modules. >It is the date of the last APEX module that successfully committed.
Why is this so complicated. It should be more intuitive. Sigh.
Jeff Layman wrote:
Is there anything of interest to you here?
<https://android.gadgethacks.com/news/android-play-system-update-shows-2024-google-explains/>
Hi Jeff,
Thanks for that article, which seems to partly explain what's going on.
My main goal was just to figure out how to *prove* that Project Mainline
was working, but then it got complicated 'cuz the Galaxy doesn't show
what's in /apex (while the Pixels apparently do show what is in /apex), so I'm not sure if Project Mainline is working or not on my modified Samsung.
I'm not sure what the "version" of Google Play system update means with respect to Project Mainline, so your article is helpful in that regard.
*Android Play System Update Shows 2024? Google Explains (Feb 6, 2026)*
<https://android.gadgethacks.com/news/android-play-system-update-shows-2024-google-explains/>
Apparently the date in Settings > Security > Google Play system update reflects the timestamp of just one specific module file and worse,
(verbatim) "The situation gets even more complex when you consider that Samsung has been blocking Play system updates for months following major Android updates, a pattern that has reportedly persisted for years"
All I'm really trying to do is determine how to tell, for sure, that
Project Mainline is updating modules monthly, on any given Android device.
My assumption was that I could check the date stamps (or version data)
on the APEX (Android pony express) modules, but apparently Samsung's don't allow permission in /apex (where apparently the Pixels do allow it).
I was also hoping that the Google Play system update date would be--
useful in that regard, but apparently, based on the article you kindly unearthed, that may not be as meaningful as I might have hoped it to be.
Jeff Layman wrote:
It's Android 13, and according to Settings the last security update was
1 Sept 2023.
Google Play system updates continue after android security updates are finished for a given model.
On my Android 13 Samsung Galaxy A32-5G, longpressing on the "Google Play system update" in the Settings > About phone > Software information doesn't do anything but of course, my April 2021 SM-A326U phone is out of support. Android Security Patch Level = February 1, 2025
AJL wrote:
Hence, the "Google Play system update" date is not the date of all modules. >>>It is the date of the last APEX module that successfully committed.
Why is this so complicated. It should be more intuitive. Sigh.
I would say for us less technical folks it definitely should be more
automatic. I don't keep sensitive stuff on my 6 year old Samsung phone
because I don't expect security on it to be up to date. Likewise my other >> lower Android versioned toys. However I do (did?) expect it of this brand >> new Android 16 Samsung tablet. It brags about automatic updates for 6
years. And so I do keep sensitive stuff on it. Thus finding something on it >> that needs a manual update is a bit disconcerting even though it is
explained away by some website...
Hi AJL,
I agree with you that it should be "automatic", but apparently it's not.
Since others have seen the same thing, we're pretty sure now, by joint >experience anyway, that the Google Play system update must be proceeding in >two distinct stages, one of which is manual, which isn't intuitive to us.
Stage 1: Google Play system update silently downloads modules into a
staging area (which appears to change depending on the OEM).
(maybe /data/apex/sessions/?)
Stage 2: But it requires a reboot for those /apex files to be mounted
<https://android.googlesource.com/platform/system/apex/+/refs/heads/android11-mainline-permission-release/docs/>
"If an APEX is present in a built-in partition, the APEX can
be updated by providing an APEX package with the same package
name and a higher version code. The new APEX is stored in /data
and, similar to APKs, the newer version shadows the version
already present in the built-in partition. But unlike APKs,
the newer version of the APEX is only activated after reboot."
It would be nice to know if we can figure out how to access those
apex files because that alone would be proof Project Mainline works.
AJL wrote:
If you have a Samsung, what is your Google Play system update date?
Are all Samsung's frozen? Or just mine?
This Samsung Galaxy A11+ tablet I'm posting with says November 1, 2025.
I just realized Mainline is TWO different sources, not one!
A. Google
B. Samsung (in my situation)
For Mainline to work from Google, apparently four things are needed:
1. Play Store system updater (as a system app!)
2. Google Play services (GMSCore)
3. ModuleMetadata
4. APEX subsystem must have all gthe mainline modules
(which is why removing two modules caused mainline from Google to fail)
i. AdServices
ii. Telemetry
But wait. There's more!
Samsung ALSO updates mainline packages!
(at least the Samsung-specific ones for a Samsung device)
For Mainline to work from Samsung, you don't need anything special!
So Samsung's Mainline OTA has been working just fine all this time.
Long ago, I had removed the Google Play Store <com.android.vending> package >from the user partition but apparently the SYSTEM partition package is what >matters so removing the app for the user doesn't remove the system package.
Mainline = the modular system architecture
Google Play system updates = one delivery mechanism (of two)
These are, I think, the key packages of Mainline on any Android device:
a. com.android.vending (Play Store, but installed as a system app)
b. com.google.android.gms (Google Play services Mainline orchestrator)
c. com.google.android.gms.update (Mainline updater)
d. com.google.android.modulemetadata (module manifest)
e. com.google.android.permissioncontroller (Mainline module)
f. APEX modules like com.android.adbd.apex, com.android.media.apex, etc
but if even one of them is missing from the user partition,
Mainline from Google will (apparently) fail.
Apparently Samsung uses two pipelines:
I. Google's Mainline pipeline (com.android.vending, com.google.android.gms) >II. Samsung OTA pipeline (which heavily overrides Google's modules)
So my Samsung OTA pipeline was likely still working all these years.
Even as the Google Internet pipeline was likely not working all that time.
This is the Google Play system update version.
adb shell dumpsys package com.google.android.modulemetadata | grepversion
versionName = 2023-06-01 S+
versionCode = 331851034
Note it has not changed since June 2023.
Also note codePath = /product/app/com.google.android.modulemetadata
This is a system-bundled APK because if Mainline had updated it, it would
be in /data/app/.../com.google.android.modulemetadata-xxxx/base.apk
This shows that all my APEX modules are those shipped by the factory alone!
adb shell pm list packages --apex-only
For Pixels, these will work, but not for Samsungs
adb shell dumpsys apexCan't find service: apex
adb shell ls -l /apexls: /apex: Permission denied
For Samsungs, we have to use Termux:
Termux$ cat /proc/mounts | grep apex
Since every APEX was mounted from a loopback image, that proved
Samsung's OTAs (not Google's Mainline) supplied those versions.
When Google Mainline updates an APEX, we would have seen
/data/apex/active/com.android.conscrypt@<newversion>
But everything on my system was mounted from
/dev/block/dm-*
/dev/block/loop*p*
In summary, this proves my APEX versions were the ones that
Samsung shipped in my last March 2025 OTA.
But as of today, with three changes, my device is whole again:
I. I re-installed telemetry <com.google.mainline.telemetry>
II. I re-installed adservices <com.google.mainline.adservices>
III. I updated Google Play services <com.google.android.gms>
Now my device is capable of receiving the next Mainline bundle.
It looks like we're all realizing that we have to reboot to get updates.
I think we've together figured out a few things, the most important being that we need to not only longpress the Google Play system update button,
but we also need to reboot (which that button may trigger in some OEMs).
AJL wrote:
Now my device is capable of receiving the next Mainline bundle.
I just enabled Developer Options on my new Samsung tablet and there is an
on-off switch labeled "Auto Update System" which was already turned
on. The
sentence just below it says "Apply updates when the tablet restarts." So
apparently restarts triggering/installing updates can be turned off
on this
toy...
Hi AJL,
Thanks for bringing up MORE reasons why Project Mainline might fail...
Aurgh! :)
I forgot about looking in Developer options. Let me look at mine!
Developer options > Auto update system = on
It may be on by default, as I don't remember setting it myself.
Looking up what it does, it seems to possibly be "Samsung specific"
since it appears this toggle might only affect Samsung's OTA firmware
updates (Samsung system updates) and even then, only the final
installation step:
I. When ON:
If a Samsung OTA update has already been downloaded, the device
will automatically install it the next time we reboot.
II. When OFF:
The OTA will still download normally, but the device will not
auto-apply it on reboot. We must manually confirm installation.
So, apparently that toggle is only for the OTA half of Project Mainline.
a. It won't block OTA downloads
b. It won't block OTA availability
c. It won't block Google Play system updates
d. It won't block Mainline bundles
e. It won't block Play services updates
f. It won't block modulemetadata updates
g. It won't block APEX updates
h. It won't block APK-based Mainline modules
Apparently it only controls whether an OTA installs automatically on
reboot.
But wait. There's more! Much more. Aurgh!
I don't have the Google Play store <com.android.vending> in my user partition, but most people have it so this *does* affect Mainline updates. Profile icon > Settings > Network preferences > Auto-update apps
a. Over any network
b. Over Wi-Fi only
c. Don't auto-update apps
For me, the setting isn't used since I don't have a user Play Store app.
adb shell settings get global auto_update_appsnull
Where mine isn't set to anything so it shows up as "null".
1 -> Auto-update apps is ON
0 -> Auto-update apps is OFF
null -> Play Store manages it internally (common on Samsung)
adb shell dumpsys package com.android.vending | grep -i "auto"... Action: "android.intent.action.AUTO_REVOKE_PERMISSIONS"
Where mine is not active in the user partition, but for others
auto_update=1 -> Auto-update apps is enabled
auto_update=0 -> Auto-update apps is disabled
(Which means Mainline APK modules will not update)
Yikes! It's worse than I had thought it would be!
If the user-partition Google Play app isn't updating APKs,
then Mainline may (will?) fail because it's an all-or-nothing bundle!
Because Mainline bundles contain two types of modules:
a. APEX modules (updated atomically)
b. APK modules (updated through the Play Store) If *any* of those
bundles are "old", Mainline "may" fail to update!
There are three Play Store components that must exist and be active:
1. com.android.vending
a. This is the Play Store app itself.
b. Even if we never open it, it must be present because:
i. It contains the system updater service.
ii. It contains the job scheduler for Mainline.
iii. It contains the module delivery logic.
c. adb shell pm path com.android.vending
(mine reports nothing)
(yours may report /system/priv-app/Phonesky/Phonesky.apk)
d. adb shell pm list packages -d | grep vending
(again, mine reports nothing)
e. adb shell dumpsys activity processes | grep -i vending
(mine reports nothing)
2. com.google.android.gms (Play services)
a. This is the Mainline "brain."
(I just today updated this to a modern version.)
b. adb shell pm path com.android.vending
(Mine reports a lot of hits)
3. com.google.android.gms.unstable (this is a process, not a package)
a. This is the Play services process that negotiates Mainline bundles.
i. If any of these are missing or disabled, Mainline cannot function.
ii. My Aurora Store uploader cannot replace any of them
b. adb shell pm path com.google.android.gms.unstable
(Mine reports nothing)
It gets confusing, but adb will tell us what is going on in reality.
adb shell pm list packages | grep -E"extservices|adservices|telemetry|mediaprovider"
package:com.google.mainline.telemetry
This is for a. crash reporting
b. system health metrics
d. update diagnostics
package:com.google.android.adservices.api
package:com.google.mainline.adservices
This is for
a. Android Privacy Sandbox APIs
b. on-device ad measurement c. app-to-app attribution
without identifier
adb shell dumpsys package com.google.mainline.telemetry | grep -i"codePath"
codePath=/apex/com.android.adservices/priv-app/AdServicesApkGoogle@331814200
adb shell dumpsys package com.google.android.adservices.api | grep-i "codePath"
codePath=/data/app/~~rQOKjWIC_nHDInzudemw4A==/com.google.mainline.adservices-t58s2aeOs6X3jb0AANMqVw==
codePath=/product/app/com.google.mainline.adservices
adb shell dumpsys package com.google.mainline.adservices | grep -i"codePath"
So even though today I re-installed 2 APKs manually (telemetry &
adservices), I must re-install com.android.vending for Mainline to work. Sigh. C:\> adb shell cmd package install-existing com.android.vending
i. Note that I do not need to sign in for Mainline to work.
ii. I do not need to use the Play Store for Mainlikne to work.
iii. I do not need to install apps with com.android.vending either.
Drat. I hate having to install the Play Store on Android, even as I
can't use it since I don't have a Google Account on Android.
But, apparently, the Play Store isn't just an app downloader.
i. The Play Store is the Mainline APK module updater
ii. It's the Mainline bundle downloader
iii. And it's the modulemetadata updater
iv. It's also apparently the APEX/APK dependency validator
v. And, apparently it's the scheduler for Mainline update jobs
Play services is the "brain," but the Play Store is the "delivery system."
a. Without it, Mainline can't update anything.
b. Sigh. I hate non-intuitive complexity.
c. Specifically, I hate having to have the Google Play Store installed.
To check that the Play Store is installed and running, I ran:
adb shell pm list packages | grep vendingpackage:com.android.vending
adb shell dumpsys activity processes | grep -i vending(lots of output)
*APP* UID 10217 ProcessRecord{5bb08c8
28078:com.android.vending/u0a217}
That means it's running as a normal user process now.
adb shell settings get global auto_update_appsnull
a. If it were 0, that would block Mainline APK modules.
b. If it were 1, it would explicitly allow them.
c. null means "Play Store decides," which is acceptable
To check whether the Play Store has registered its Mainline update jobs
with the system scheduler.
adb shell dumpsys jobscheduler | grep -i vendingJOB #u0a217/9004: com.android.vending/com.google.android.finsky.scheduler.process.mainimpl.PhoneskyJobServiceMain
Means the Play Store has registered its main scheduler with the
system JobScheduler
a. PhoneskyJobServiceMain (main update scheduler)
b. PhoneskyJobServiceBackground (background update tasks)
c. InstantAppHygiene, PhenotypeUpdate, StatusSync (normal auxiliary jobs)
Note there isn't a "MainlineJobSky" as it's hidden inside of Phonesky!
adb shell dumpsys jobscheduler | grep -i finsky(Because "finsky" is the internal name for the Play Store.)
To check whether the Play Store has registered its system update
permissions correctly
adb shell dumpsys package com.android.vending | grep -i permission
To confirm whether the Play Store has the privileges required to apply Mainline modules.
adb shell dumpsys package com.android.vending | grep -i"android.permission.UPDATE"
To confirm whether my Mainline APEX modules are in a consistent state.
adb shell pm list packages --apexThat won't work for Samsung though.
Termux$ cat /proc/mounts | grep apex This shows all core Mainline modules exist.
Confirm that the APK-based modules I restored (Telemetry, AdServices,
etc.) are registered and visible to the system.
adb shell pm list packages | grep mainline
Check whether the modulemetadata file exists and is readable.
adb shell ls -l /data/system/modulemetadata.xmlls: /data/system/modulemetadata.xml: No such file or directory
adb shell ls -l /metadata/modulemetadata.xmlls: /metadata/modulemetadata.xml: No such file or directory
adb shell dumpsys modulemetadataCan't find service: modulemetadata
Hmmm... apparently my device never had the Mainline metadata subsystem active.
The absence of modulemetadata indicates Mainline has never been run!
Because modulemetadata.xml is only created when Google pushes a Mainline bundle.
But since I have a full set of Mainline modules, it's Samsung's OTA
which has been updating them all along. Not Google's Mainline updater.
Hopefully, the next Mainline bundle Google pushes will create the modulemetadata service and the XML file automatically.
AJL wrote:
I said that PhoNews was working OK on my Samsung Android 16 tablet. I
lied. I made a reply to this post that it said that it transmitted but
it didn't. Then a new problem popped up. It no longer saw all the
newsgroups. So I've given up on it. My solution? I got a new toy of
course. This AWOW Windows 11 tablet I'm (I hope) posting with. Its the
first tablet I've owned that gets warm and has a fan. In fact during its
startup updates it got almost too hot to touch. And battery life is
dismal. So far not impressed but hey it's something new to play with and
I'm still here. Guess I'll go look at the Windows groups now too...
Interesting that PhoNews bailed out on you after all. Bummer.
A tablet with a fan. Wow. Lots of laptops don't even have fans.
"These chips are efficient, but they still produce more heat than
ARM chips found in iPads or Android tablets. To prevent overheating,
the device includes a small internal cooling fan, a heat sink
connected to the CPU, and air vents for airflow."
I had never heard of that tablet so I looked it up. Apparently "the AWOW >Windows 11 tablet is a budget-friendly 10.1-inch 2-in-1 device that >functions as both a tablet and a mini laptop, typically bundled with a >detachable keyboard and running full Windows 11".
12GB RAM and 256GB SSD
Intel N150 or N100 low-power CPU
Intel UHD integrated graphics
10.1" in-cell touchscreen, 1920px resolution
WiFi 6, Bluetooth 5.0, USB-C, HDMI
8MP rear + 5MP front
36W PD fast charging
Windows 11 Home
I set up Windows 11 recently for a school kid on a new desktop where I was >able to easily circumvent the MSA requirement if you're interested in that.
Newsgroups: alt.comp.os.windows-11,alt.comp.hardware.pc-homebuilt,alt.comp.microsoft.windows
Subject: PSA: I can happily report that my first Win11 Home installed sans a MSA
Date: Mon, 12 Jan 2026 15:24:16 -0500
Message-ID: <10k3l9g$2ug$1@nnrp.usenet.blueworldhosting.com>
Privacy is what you bake into the device from the moment you turn it on.
AJL wrote:
Interesting that PhoNews bailed out on you after all. Bummer.
Well, that's apparently for Android 16 (so far). I'll do this PhoNews post >> on a Chromebook on which it has worked in the past. I'm not sure what
version of Android the Chromebook imitates but if you're curious PhoNews
should tell you what it thinks it is in the headers.
Your header shows
"User-Agent: PhoNews/3.13.3 (Android/13)"
Hey. That's the same as mine! :) (jk)
Another problem with PhoNews is that it's difficult to crosspost. Extra
newsgroups must be typed in manually even when answering a crossposted
post. A PITA but then I'm sure some would perhaps call it a feature...
Actually, my 'newsreader' is similarly afflicted. It doesn't automatically >inherit ngs, so I have sometimes made typos when I typed the newsgroups.
12GB RAM and 256GB SSD
Intel N150 or N100 low-power CPU
Windows 11 Home
Yup. That's my new toy.
Nice. I can't use "small stuff" anymore, due to my declining eyesight.
My monitor is a Sharpe LC45GD7U which is about a hundred pounds as it's old >tech, but being a "45-inch" monitor, my Android is mirrored two feet tall!
Actually it's 22 inches tall (not 24). And 39 inches wide.
With the phone being 22 inches tall I can finally see all the buttons.
I set up Windows 11 recently for a school kid on a new desktop where I was >>>able to easily circumvent the MSA requirement if you're interested in that. >>Thanks but no thanks. I did use my fake name/email to sign in though. I'll >> let you in a the secret, the initials are AJL... ;)
I completely understand why most people do exactly what they're told to do.
I'd never do well in the military as I'm always doing what I think needs to >be done, so I don't do what Microsoft or Apple or Google tell me to do.
I see no advantage, to the user, of creating any account on the device. >None.
Do you?
Newsgroups: alt.comp.os.windows-11,alt.comp.hardware.pc-homebuilt,alt.comp.microsoft.windows
Subject: PSA: I can happily report that my first Win11 Home installed sans a MSA
Date: Mon, 12 Jan 2026 15:24:16 -0500
Message-ID: <10k3l9g$2ug$1@nnrp.usenet.blueworldhosting.com>
Privacy is what you bake into the device from the moment you turn it on.
Not me. I figure my life is pretty much already in the sky and unless you
live in a cave so is yours. But we've have hashed that out on several
occasions before so no need for a repeat....is there?? 8-O
Agreed. Once you own a home in the USA, and once you vote in the USA, and >once you go to college (and get student loans) in the USA, and once you
open a SSN in the USA and a bank account, you're on the blackboard forever.
Still, I just want to make a point that only Apple forces the mothership >account, and the biggest threat to privacy, bar none, is that account.
Glad you have a new toy to work with. I hope you put it to a lot of good >use.
There's the Windows newsgroups if you need to ask any questions.
alt.comp.os.windows-11
Andy and Carlos are frequent posters. As am I.
| Sysop: | Jacob Catayoc |
|---|---|
| Location: | Pasay City, Metro Manila, Philippines |
| Users: | 5 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 117:54:06 |
| Calls: | 125 |
| Calls today: | 125 |
| Files: | 489 |
| D/L today: |
859 files (365M bytes) |
| Messages: | 76,488 |
| Posted today: | 26 |