Not in Android but definitely for an android successor OS
this post was submitted on 09 Jun 2025
67 points (98.6% liked)
Android
30688 readers
131 users here now
DROID DOES
Welcome to the droidymcdroidface-iest, Lemmyest (Lemmiest), test, bestest, phoniest, pluckiest, snarkiest, and spiciest Android community on Lemmy (Do not respond)! Here you can participate in amazing discussions and events relating to all things Android.
The rules for posting and commenting, besides the rules defined here for lemmy.world, are as follows:
Rules
1. All posts must be relevant to Android devices/operating system.
2. Posts cannot be illegal or NSFW material.
3. No spam, self promotion, or upvote farming. Sources engaging in these behavior will be added to the Blacklist.
4. Non-whitelisted bots will be banned.
5. Engage respectfully: Harassment, flamebaiting, bad faith engagement, or agenda posting will result in your posts being removed. Excessive violations will result in temporary or permanent ban, depending on severity.
6. Memes are not allowed to be posts, but are allowed in the comments.
7. Posts from clickbait sources are heavily discouraged. Please de-clickbait titles if it needs to be submitted.
8. Submission statements of any length composed of your own thoughts inside the post text field are mandatory for any microblog posts, and are optional but recommended for article/image/video posts.
Community Resources:
We are Android girls*,
In our Lemmy.world.
The back is plastic,
It's fantastic.
*Well, not just girls: people of all gender identities are welcomed here.
Our Partner Communities:
founded 2 years ago
MODERATORS
They do push some apps to implement sEcUrItY messures, so they can verify that that they are installed via the official store. I can't use the fucking unloc app due to that. So...i wouldn't be surprised if there is more of this coming, but i sure hope there isn't...
US maybe, EU doubt
It's a legal trend now to force enable users to sideload so I doubt Google wants to pull back on one thing that they are not being sued over.
That's not how corporates think though. The ONLY thing that matters to them is number go up next month. Surprising customers with new fees for things they rely on is an easy way to do that. Guaranteed they'll try it.
"Yeah, you can sideload the apps, but they're not allowed to use any of your permissions, making them functionally useless" - Google soon probably
Probably not. If Google could survive the Amazon App Store, it doesn't have a reason to restrict sideloading now.
I don't love the term "sideloading". It sounds like something more nerdy and less normal that just installing software from a source of the user's choice.
No, I don't think it's likely Google will try to prevent it. That would violate the DMA in the EU, and several other jurisdictions have moved toward forcing Apple to allow software installation outside its app store. Between that and antitrust lawsuits in the USA, I think it's very unlikely Google wants to attract more scrutiny from regulators.
Google outright lets you unlock your bootloader on Pixels, and relock it with your custom keys, and even tells you how to do all that in the docs. You lose Play Integrity certification which is where things are getting a bit messy.
But for that you have to blame Amazon, Netflix, Hulu, Disney, a lot of banks, a lot of games for using what is basically DRM for apps. It's the developers that want those features, so you can't mod their APKs and take the ads out, make sure you download the official version from Google Play because dumb users getting scammed and all that stuff.
I run LineageOS on my phone, I'm not doing anything whatsoever to hide it, and pretty much everything works perfectly except Google Pay. Which I guess is fair game, I hate it but there's a reasonable argument to be made there.
The rest is the same DRM woes I deal with on Linux, I value my rights and freedoms more than running an app.
But for that you have to blame Amazon, Netflix, Hulu, Disney, a lot of banks, a lot of games for using what is basically DRM for apps.
I don't think those entities had the leverage to force Google to add remote attestation to Android. Safetynet didn't show up until 2014 when Android was already established enough that not being on Android wasn't a realistic option for any of them.
Instead, I think it was mainly a move by Google to make it so any OEM shipping a fork of Android without Google's blessing would have angry users because some of their apps wouldn't run.
Google bought Widevine in 2010, so in my opinion they were already concerned about big corp's interests above the users well before. I think SafetyNet is the natural evolution of that.
I think SafetyNet came with Google Pay for contactless payments, most likely at the request of the banks. They had to work with the banks for that, that's when they got the leverage. If they didn't they'd just go partner with Samsung instead, who already had Knox, and I did see Samsung Pay on my phone before Google Pay was available at all.
They also had to increasingly deal with shitty root detection libraries that were getting popular and excluding legitimate users because the latest Android changed things enough it looked modded to the apps. They probably saw it as a lesser evil to just take it in their hands.
You don't need that much leverage to put enough pressure that there's enough demands for a feature for the feature to get added. Android was dealing with a lot of fragmentation, piracy and quality problems already, Google needed people to see Android as not just the shitty budget option, they wanted to compete with the iPhone proper.
The entheusiast market only gets you so far. You need entheusiast buy-in at first, but then you have to pivot to end user "premium" experience, which is why brands like OnePlus eventually turn their back to the users that propped the company up. Regular users would rather pick the walled garden than the open world if it means their apps work better in the walled garden. The walled garden is a better experience for the average moron.
Google is concerned with its own interests and only behaves as if it's concerned with anyone else's when there's a perceived benefit to Google.
There's a chance the preferences of some app developers were a contributing factor for Google, but I'm convinced it was about reigning in OEMs more than anything else. Your comment cites fragmentation, and there were things like Fire Phone from Amazon that didn't ship with Google services. Fire Phone failed because it wasn't good, but if Amazon had iterated on it or someone else had done a better job, it might have taken a big chunk out of Google's Android profits.
excluding legitimate users
I hate this framing.
I'm generally disappointed there wasn't more outcry about Google creating a remote attestation scheme. Microsoft proposed one for PCs a decade earlier and the New York Times called it out as a corporate power grab. I'm not sure if there was a general shift in thinking, if people thought about phones differently from PCs, or if Google had enough of that "don't be evil" glow people didn't question it.
Why did you choose Lineage over Graphene?
Because I have a OnePlus.
Gocha. I thought I had read that you had a Pixel.
Which model - if you don't mind my asking? I managed to get my old Samsung A21s working *almost" perfectly with LineageOS.
It's a OnePlus 8T, but I think any OnePlus before I think the OnePlus 11 have excellent custom ROM support.
AFAIK I got lucky and the 8T is the last model from their "being nice to developers" era. OnePlus was born originally to be developer friendly, it was based on CyanogenMod out of the box, they even sent phones to developers.
Mine launched with OxygenOS 11, and then OOS12 was completely rebuilt on Oppo's ColorOS and they threw everything out the window. Took them forever to drop sources, and it just went downhill from there.
Yeah. The idea was an older one for cheap. Anything really that will allow my banking app to work.
I just lucky with the Samsung, the banking app works, but I didn't check first.
It doesn't solve Safety Net/Play Integrity, at all. My bank is the kind that just warns you and then lets you in anyway. I just live without Google Pay, I just put the card in the phone case to the same effect. The point I was making there is that most apps don't care, Google isn't "pushing" it, but it is made available to developers, so really it's the app developers' choice to check or not.
Pixels are just less fiddling because flashing it is supported. It is not endorsed by Google, and you don't pass Play Integrity at all, but it is supported and doesn't void your warranty. They just allow you to install whatever you want on your hardware without a fuss, and get the full performance you'd expect and all, and even make use of the security chip. But, they only trust their code and their ROM for the purposes of Play Integrity, which is kinda fair game.
That's why it is quite ironically the device of choice for GrapheneOS. It's not a hack, it's a fully supported use case even though you lose Play Integrity certification, so they can implement all the security features Google has access to. The TEE will happily sign a unique and verifiable integrity attestation... for GrapheneOS's ROM signature. You can make an app that only works on genuine official GrapheneOS the same other apps do with Play Integrity. You can have a custom ROM and properly enroll it in some enterprise MDM and all that stuff, and only allow your builds of that custom ROM to enroll. But, no Play Integrity because it's not their official certified build.
It's like PC, you can turn off secure boot, you can secure boot with your own OS keys and get all the security benefits. But Valorant will still refuse to let you play if you haven't booted with secure boot into an official unmodified copy of Windows where they can ensure their kernel anti-cheat can trust the kernel about what drivers and processes are loaded. Microsoft isn't forcing their OS on you, but the developers will only trust you if you do. You're still perfectly free to put Linux on it, and it won't affect you otherwise.
I might have to get one. My Samsung is still a bit slow - and old.
If you're buying something to mod I'd recommend a Pixel, unless you're getting an older OnePlus for cheap.
I don't foresee Google as in a hardware/phone supplier company ever doing that. The chance of monopoly due to other clauses are too high.
Being said, I do foresee them introducing a way in Android to restrict sideloading completely, so it imitates how Apple has their environment. However, I don't foresee it becoming super popular, especially with how hard the EU is pushing for people to have more freedom with their devices.
After the Apple ruling basically forcing them to allow side loading, I doubt google would even be able to.
Additionally, Google has already been targeted for its monopolising behaviour in the advertising space. It probably doesn't want to add fuel to the fire by completely locking down its mobile ecosystem.
The harder they push, the more it incentivises someone else to sell actual open source hardware for profit.
We can keep dreaming, I guess. But no, it doesn't, because the big players aren't making that possible. In the literal sense. That would be easy on a x86, but not with arm.
I think the Chinese will do it with RISC-V, or Europe will demand it independently.
We're on the last nodes for fabs. The era of exponential growth is over. It is inevitable that a major shift in hardware longevity and serviceability will happen now. Stuff will also get much more expensive because volume is not needed or possible in the cycle to pay back the node investments.
I must admit I don't know enough about RISC-V performance. How's it with battery life? That's the one reason why no (mass-produced) phone or tablet will ever be made with an x86, so unless RISC-V is on-par (or better) with arm, it won't succeed.
ARM is an older Reduced Instruction Set Computing out of Berkeley too. There are not a lot of differences here. x86 could even be better. American companies are mostly run by incompetent misers that extract value through exploitation instead of innovation on the edge and future. Intel has crashed and burned because it failed to keep pace with competition. Like much of the newer x86 stuff is RISC-like wrappers on CISC instructions under the hood, to loosely quote others at places like Linux Plumbers conference talks.
ARM costs a fortune in royalties. RISC-V removes those royalties and creates an entire ecosystem for companies to independently sell their own IP blocks instead of places like Intel using this space for manipulative exploitation through vendor lock in. If China invests in RISC-V, it will antiquate the entire West within 5-10 years time, similar to what they did with electric vehicles and western privateer pirate capitalist incompetence.
Like much of the newer x86 stuff is RISC-like wrappers on CISC instructions under the hood
I think it's actually the opposite. The actual execution units tend to be more RISC-like but the "public" interfaces are CISC to allow backwards compatibility. Otherwise, they would have to publish new developer docs for every microcode update or generational change.
Not necessarily a bad strategy but, definitely results in greater complexity over time to translate between the "external" and "internal" architecture and also results in challenged in really tuning the interfacing between hardware and software because of the abstraction layer.
You caught me. I meant this, but was thinking backwards from the bottom up. Like building the logic and registers required to satisfy the CISC instruction.
This mental space is my thar be dragons and wizards space on the edge of my comprehension and curiosity. The pipelines involved to execute a complex instruction like AVX loading a 512 bit word, while two logical cores are multi threading with cache prediction, along with the DRAM bus width limitations, to run tensor maths – are baffling to me.
I barely understood the Chips and Cheese article explaining how the primary bottleneck for running LLMs on a CPU is the L2 to L1 cache bus throughput. Conceptually that makes sense, but thinking in terms of the actual hardware, I can't answer, "why aren't AI models packaged and processed in blocks specifically sized for this cache bus limitation". If my cache bus is the limiting factor, duel threading for logical cores seems like asinine stupidity that poisons the cache. Or why an OS CPU scheduler is not equip to automatically detect or flag tensor math and isolate threads from kernel interrupts is beyond me.
Adding a layer to that and saying all of this is RISC cosplaying as CISC is my mental party clown cum serial killer... "but... but... it is 1 instruction..."
You caught me. I meant this, but was thinking backwards from the bottom up. Like building the logic and registers required to satisfy the CISC instruction.
Yeah. I'm from more of a SysAdmin/DevOps/(kinda)SWE background so, I tend to think of it in a similar manner to APIs. The x86_64 CISC registers are like a public API and the ??? RISC-y registers are like an internal API and may or may not even be accessible outside of intra-die communication.
This mental space is my thar be dragons and wizards space on the edge of my comprehension and curiosity. The pipelines involved to execute a complex instruction like AVX loading a 512 bit word, while two logical cores are multi threading with cache prediction, along with the DRAM bus width limitations, to run tensor maths – are baffling to me.
Very similar to where I'm at. I've finally gotten my AuADHD brain to get Vivado setup for my Zynq dev board and I think I finally have everything that I need to try to unbrick my Fomu (it doesn't have a hard USB controller so, I have to use a pogo pin jig to try to load a basic USB softcore that will allow it to be programmed normally).
I barely understood the Chips and Cheese article explaining how the primary bottleneck for running LLMs on a CPU is the L2 to L1 cache bus throughput. Conceptually that makes sense, but thinking in terms of the actual hardware, I can't answer, "why aren't AI models packaged and processed in blocks specifically sized for this cache bus limitation". If my cache bus is the limiting factor, duel threading for logical cores seems like asinine stupidity that poisons the cache. Or why an OS CPU scheduler is not equip to automatically detect or flag tensor math and isolate threads from kernel interrupts is beyond me.
Mind sharing that article?
Adding a layer to that and saying all of this is RISC cosplaying as CISC is my mental party clown cum serial killer... "but... but... it is 1 instruction..."
I think that it's like the above way of thinking of it like APIs but, I could be entirely incorrect. I don't think I am though. Because the registers that programs interact with are standardized, those probably are "actual" x86, in that they are to be expected to handle x86 instructions in the spec defined manner. Past those externally-addressable registers is just a black box that does the work to allow the registers to act in an expected manner. Some of that black box also must include programmable logic to allow microcode to be a thing.
Its a crazy and magical side of technology.
Oh wow, so we are in kinda similar places but from vastly different paths and capabilities. Back before I was disabled I was a rather extreme outlier of a car enthusiast, like I painted (owned) ported and machined professionally. I was really good with carburetors, but had a chance to get some specially made direct injection race heads with mechanical injector ports in the combustion chamber... I knew some of the Hilborn guys... real edgy race stuff. I was looking at building a supercharged motor with a mini blower and a very custom open source Megasquirt fuel injection setup using a bunch of hacked parts from some junkyard Mercedes direct injection Bosch diesel cars. I had no idea how complex computing and microcontrollers are, but I figured it couldn't be much worse than how I had figured out all automotive systems and mechanics. After I was disabled 11 years ago riding a bicycle to work while the heads were off of my Camaro, I got into Arduino and just trying to figure out how to build sensors and gauges. I never fully recovered from the broken neck and back, but am still chipping away at compute. Naturally, I started with a mix of digital functionality and interfacing with analog.
From this perspective, I don't really like API like interfaces. I often have trouble wrapping my head around them. I want to know what is actually happening under the hood. I have a ton of discrete logic for breadboards and have built stuff like Ben Eater's breadboard computer. At one point I played with CPLDs in Quartus. I have an ICE40 around but have only barely gotten the open source toolchain running before losing interest and moving on to other stuff. I prefer something like Flash Forth or Micropython running on a microcontroller so that I am independent of some proprietary IDE nonsense. But I am primarily a Maker and prefer fabrication or CAD over programming. I struggle to manage complexity and the advanced algorithms I would know if I had a formal CS background.
So from that perspective, what I find baffling about RISC under CISC is specifically the timing involved. Your API mindset is likely handwaving this as black box, but I am in this box. Like, I understand how there should be a pipeline of steps involved for the complex instruction to happen. What I do not understand is the reason or mechanisms that separate CISC from RISC in this pipeline. If my goal is to do A..E, and A-B and C-D are RISC instructions, I have a ton of questions. Like why is there still any divide at all for x86 if direct emulation is a translation and subdivision of two instructions? Or how is the timing of this RISC compilation as efficient as if the logic is built as an integrated monolith? How could that ever be more efficient? Is this incompetent cost cutting, backwards compatibility constrained, or some fundamental issue with the topology like RLC issues with the required real estate on the die?
As far as the Chips and Cheese article, if I recall correctly, that was saved once upon a time in Infinity on my last phone, but Infinity got locked by the dev. The reddit post link would have been a month or two before June of 2023, but your search is as good as mine. I'm pretty good at reading and remembering the abstract bits of info I found useful, but I'm not great about saving citations, so take it as water cooler hearsay if you like. It was said in good faith with no attempt to intentionally mislead.
It has definitely been a goal. How far they'll get with legislators against them, I dunno. But it's what Pinchai and the people in control wanted because they think it's part of what made Apple powerful