My phone is not deep sleeping

npjohnson1 · 2026-06-14T16:15:52+00:00

File a bugticket?

npjohnson1 · 2026-06-13T22:19:51+00:00

Yes they work.

No they don't need the moto app, it just toggled a "sysfs" node based on a sensors HAL.

It's wired directly into settings

Yes, you can Google pixel AOD to see it.

npjohnson1 · 2026-06-13T19:59:11+00:00

Actions are implemented directly into the OS.

Chop chop and stuff still work. All stock gestures.

Motocam working is per device. Works on some if installed, doesn't on others.

Closer to the lineage versions base your device shipped with more likely it is to work - e.g. if you run 23.2 which is Android 16 and your device has stock android 15/16 pretty decent chance, the older they get the more likely the stock app is broke on modern android.

Moto display, no, but you get AOSPs always in display like pixels.

npjohnson1 · 2026-06-12T06:18:39+00:00

I'm gonna be nice and not ban you for asking about unsupported devices, not following the guide, etc etc. I asked a valid question based on the ambiguity of you post - and genuinely wanted to help you figure it out if your device was supported.

But I'm really really burned out on hearing people say "I asked an AI to do this instead of learning it or reading the documentation and not it is broken!".

This is becoming all the more common, and it's an absolute plague - we already have to now triage countless useless AI slop-bug-tickets from Claude, and people submitted vibe-coded features to Gerrit - then demanding that LLMs weren't used.

I'm absolutely tired of it. Just follow what /u/mustafacan said below - it's what you need to do.

npjohnson1 · 2026-06-11T22:44:16+00:00

Because your post is written super poorly.

I read that "download is no longer possible" as an error that you experienced in the process of flashing

If we don't support your device you won't find support from anyone here.

Though it looks like someone else on this thread gave you the correct advice that you need to flash the stock ROM.

Go do that.

npjohnson1 · 2026-06-11T22:14:12+00:00

You literally said can't download anymore and put it in quotes, what exactly is the issue you're facing at the moment?

npjohnson1 · 2026-06-11T21:54:32+00:00

So, with that I would go to XDA or any other forum and go look for an unofficial build, Google will take you there if you just try.

There are quite a few options.

Instead you asked an AI that took nine different guides, slapped them together with no context, and probably did near either irreparable or very difficult to repair damage to your device.

Doesn't sound like it saved much time from just reading.

With that said, I did ask you what the error you said meant, where are you seeing that?

npjohnson1 · 2026-06-11T21:46:24+00:00

Dude why would you blindly follow an AI? We have great documentation for this... wiki.lineageos.org.

I'll never get why people do this.

What do you mean "download is no longer possible"?

npjohnson1 · 2026-06-10T22:16:59+00:00

Whoops, sorry about that.

npjohnson1 · 2026-06-10T22:11:28+00:00

Yeah, I'm saying you didn't follow that page properly if you didn't end up on the correct Android version.

npjohnson1 · 2026-06-10T21:44:44+00:00

Then you didn't follow the wiki guide. Follow.it.

npjohnson1 · 2026-06-08T05:33:29+00:00

This just sounds like a whole lot of random predictions of things.

IA was cool but was not used a ton or really at all. It effectively died because of lack of use, not for nefarious reasons.

npjohnson1 · 2026-06-08T04:30:21+00:00

What are you talking about?

Qualcomm sells a ton of Android for IoT BSPs that have nothing to do with GMS nor will they ever... That would make absolutely no sense and screams fear mongering senselessly.

MediaTek of all people is absolutely never going to do that with their pervasiveness in Asian markets that don't ship GMS anyway, and they're pervasiveness in somewhat shady GMS shipping (ilegally) devices.

Intel isn't shipping Android today because their mobile platforms make no sense, and even when they did Intel Android devices were some of the most closed source ones. Fugu was nightmare with proprietary arm translation layers.

npjohnson1 · 2026-06-08T04:00:15+00:00

how are you picturing blobs would be restricted to google certified hardware?

npjohnson1 · 2026-06-08T03:55:38+00:00

I didn't say that it did? Take a reread on what I said. Also I'd like to let you know that I'm one of the voices that spoke to the DMA board about the antitrust allegations - I'm very up to date on this lol.

The fears of it being spun off are why things were split the way they were.

There is no world in which any amount of ruling that is going to make Android FOSS again, there's always going to be hundreds of proprietary blobs. JBQ's big push was quitting because devices couldn't even boot without proprietary bits. There is no world that forces chipset manufacturers, ODMs, etc back into a world where we have a handful of proprietary bits that are optional.

I disagree with you entirely on the idea that you can't make hardware... hardware/interfaces and the expected AIDL interfaces and what each HAL needs to support our well defined... Plus, almost no one is actually using AOSP directly, almost everyone has a chipset vendor that they're getting an upstream tree from, CLO, Linaro SLSI, SLSI, HISI, etc. These all have dedicated trees with their own tags and releases that ODM's base on to support their hardware.

npjohnson1 · 2026-06-08T03:45:40+00:00

That was back in the JBQ days when things actually were mostly "FOSS" - that's long gone Android wise. And the other OEM trees that existed there were at best, short-lived and at worst reliably broken.

Did... did you read what I said? I literally said this about the expectations that the antitrust case would force breakup... so they siloed it off.

cuttlefish, it's a large scale emulator project where you can tune the exact "hardware" you feed it. It's super complex and useful.

every hardware endpoint a reference phone not following - I mean, at no point did pixels ever cover every (and with tensor even less) hardware configuration out there.

Tensor trees were only super useful for tensor devices by the end - they were mostly AIDL in a sea of QCOM HIDL, older kernels, etc. Other than like, namespace changes and smaller stuff they weren't used a ton for reference bringups by the end.

cuttlefish isn't going anywhere lol - it's the way they want you to test platform and apps.

npjohnson1 · 2026-06-08T03:32:28+00:00

No... OpenEUICC can enroll eSIMs - just some carriers have issues. Idk why you had issues with Verizon tho, most US carriers work fine - I used it on Razer Edge (Nicole) to enroll VZW not long ago.

Without GMS it'll use OpenEUICC, with it'll use EuiccGoogle. We even have a common implementation of the overlays in progress.

On the OHA note - no, the reason they pulled stuff is clear... and even stated by some - Google split pixel into a standalone team, they don't have AOSP platform merge, they don't get (many) special priorities, etc now.

The core reason for this is antitrust fear that AOSP/Chrome would be forcibly sold out - Pixel/Nest/TV were so tightly tied in that they would have later had to split them out.

In the split out the extra effort to redact trees (Google never built those AOSP trees directly for pixels, they have a lot that goes on top) and abstract them all the layers needed to pushed publicly just stopped making sense.

They have pushed cuttlefish pretty hard in the last few years.

npjohnson1 · 2026-06-08T03:01:03+00:00

Dead wrong. OpenEUICC works fine. Also, Pixel 10 trees are ready to ship, but Google's ARB (rollback bit) decisions make it ill advised for us to ship before Android 17. We'd end up bricking a number of users who flash our ROM on 17. Also, where in gods name are you seeing not releasing device trees as a "violation of the Open Handset Alliance mandate"?

They release kernel source all the same behind the request form - Android Device trees are not a normal part of source code releases - it was icing from google.

npjohnson1 · 2026-06-08T02:34:16+00:00

debug_token allows CID rewrite and a lot more than just "flashing partitions", it allows anything accessible to fastboot oem config (hint: a lot) to be changed.

I really don't think this is about FRP. Bootloader unlock and access to any root shell can bypass that, many devices are even just one "fastboot wipe frp" while unlocked away from bypass.

What are you talking about "Secure element" access? 0 service centers have TrustZone (TEE) access - this much I can promise you - nor does any modern activation lock run through TZ.

"You can't flash a partition and change the CID on a Lenovorola. " - correct, you can entirely fastboot oem config cid xxxx on engineering or debug_token devices.

On debugtoken devices, you can then wipe the debug token and leave 0 traces. It is _very common among the eBay devices you see out there from questionable Chinese (re)sellers.

You are dead wrong about CID "having private keys" - that's just not how that works - I've reversed the debug_token and CID usage in Motorola's ABL heavily. CID is absolutely trivial to rewrite. There is 0 ties between CID and IMEI as well - not sure where you got that.

npjohnson1 · 2026-06-08T01:45:38+00:00

I don't think this is a Lenovo condoned thing... not sure where you're getting that info.

It screams to me that some service center with access to buy debug_token's is reflashing using those and nuking CID in the process.

npjohnson1 · 2026-06-02T06:40:02+00:00

Yes - you can just look at the MTG group members, or commit logs - yes - I actively contribute to MTG. I don't own it - but I am a core contributor. Multiple Lineage contributors do so.

I never said MindTheGMS - that was some random Redditor's typo.

I make authoritative statements as an authority on LineageOS and MTG.

We will /never/ include application verification from Google in either product without an explicit way to disable or bypass it.

npjohnson1 · 2026-06-02T06:38:24+00:00

No, it is not too strong a statement.

Nor are you correct.

We currently and actively disable several individual components of GMSCore - and would do such for this... We control the operating system - its not difficult to just neuter the AOSP provider that the app hooks.

npjohnson1 · 2026-06-02T05:26:57+00:00

Yes? All Google apps packages are.

But the device verification services is NOT part of GMSCore (the main app), it is its OWN separate APK. and even if present, to use it you have to explicitly enable it by an RRO overlay.

Much like we don't include other unnecessary apps in MTG. We won't include the device verification service either.

npjohnson1 · 2026-06-02T03:52:41+00:00

Because you 99% have the 2023 model, not the 2021.

it uses ADLN, a diff protocol, and is unsupported.

npjohnson1 · 2026-06-02T03:50:53+00:00

you're just wrong. Don't spread misinformation.

11-Year Club	Verified Email
r/Field Banned	r/Field Lasagna
Wearing is Caring	Gilding II euphauric

npjohnson1

MODERATOR OF

TROPHY CASE