Letting you disable or limit internet access to apps would go pretty strongly against Google's interests - how would they get their ad money if half the users were running most apps offline?
Some vendors provide a way to do this (Xiaomi has an internet access toggle per app, or at least it did in the KitKat era), but it's never making its way into stock Android until Google integrates AdMob into the system.
Those distros "force" you to reboot when you want to update (as opposed to allowing you to do the update on the running system). Think Windows 7 and earlier, that kind of forced reboots, back when people were fine with the way Windows did updates.
You still need some privileged process to exploit. Glibc code doesn't get any higher privileges than the rest of the process. From kernel's point of view, it's just a part of the program like any other code.
So if triggering the bug in your own process was enough for privilege escalation, it would also be a critical security vulnerability in the kernel - it can't allow you to execute a magic sequence of instructions in your process and become a root, that completely destroys any semblance of process / user isolation.
It is, and it's the reason Pixel 6 and 7 series had so many issues with poor battery life and weak modem. Although it appears that the third generation Tensor CPUs in Pixel 8 have major improvements on both of these pain points.
Still, that probably brings Pixel 8 only to the cheap-ish midrange standard when it comes to cell signal, as the Pixel 7 phones were atrocious and 6s were apparently even worse.
They seem too small and consistent in size to just be bundles of system apps that got security fixes
Correct, just one note here: system apps (both APK apps and APEX system modules) are updated through Google Play like all other apps, the monthly security patches are a layer below that - it updates the base OS files like firmware and kernel modules. More info about APEX
Are they like differential patches or something?
Yes, that's exactly what they are. Small differential patches (often called delta patches / delta updates) to the files.
Btw apps are also getting delta updates through Google Play for at least a few years now (5-ish?)
And what happens while the 'finishing system update' notification is shown?
Android Runtime (ART) works by compiling the Java bytecode in apps to native code before running them - it's called "ahead of time compilation". This compiled native code is specific to the device, OS and system modules, and some of the modules probably changed during an update - that means the OS has to recompile all the native code against the new updated modules, and that takes some time to do for all installed apps. There can also be updates to the ART module itself that improve the way ART compiles code, and that also requires recompilation to have effect.
as far as I can tell the phone remains unlocked while updating, so why do they need it to be booted to finish the update? Is it just to turn on the phone faster?
There's a mechanism called A/B partitioning where there are actually two copies of the OS installed. To update, you copy the current OS into the other slot, then apply all the updates to it and finally mark it as the active slot. When you boot your phone, the bootloader looks up the active slot and boots it (and switches the primary slot back if it fails to boot a few times in a row).
The OS can be updated during a reboot and that's how some vendors still do it, but the downside is that the phone cannot be used during updating. With A/B partitioning and background updates, you can use your phone like usual and then reboot as quickly as any other reboot to apply the updates.
I think the idea at the time was that if /usr is unavailable, you won't be doing much with the system anyway (other than fixing the configuration).
Nevermind, apparently the original meaning had nothing to do with a network (TIL for me), so our discussion is kinda moot. See section 0.24 in this 2.9BSD (1983) installation guide
Locally written commands that aren't distributed are kept in /usr/src/local and their binaries are kept in /usr/local. This allows /usr/bin, /usr/ucb, and /bin to correspond to the distribution tape (and to the manuals that people can buy). People wishing to use /usr/local commands are made aware that they aren't in the base manual.
No comment on sensibility, but technically both are equally difficult - mount the parent filesystem, then mount the child filesystem into an empty directory in the parent. Doesn't matter which one is where, it's all abstracted away at this level anyway.
I do not get paid every time it runs for the rest of my life, so why should you?
Sorry if I misunderstood you, but this feels rather easy to answer: because you are being paid to write the code. Spotify doesn't pay anyone to write music (well maybe they technically do for some ads or something, but it's definitely not how they acquire more music to add to the library), they just pay for streaming rights on music that was somehow already independently produced. And tiny unknown musicians have no leverage to negotiate better terms than what Spotify offers.
Yeah, OP literally said that they weren't blocked when using Vivaldi with uBlock Origin, you were the first one to mention the builtin adblock (which is detected by YouTube).
Again: to use YT, you have to disable the builtin adblock and use only uBO. That's in line with OPs statement.
That's cool, but YouTube detects Vivaldi's built in adblocker, so it's kinda irrelevant if it's affected by extension policies.
To use YT in Vivaldi, you have to properly configure uBlock Origin (avoid extra filters that interfere with YT) and disable the builtin adblock for YT. And given that Vivaldi relies on Chrome Extension Store for its extensions, there will still be some friction to getting Mv2 extensions after Google pulls the plug on them.
Generally yes. The Fn key is usually handled either by the keyboard itself or by the BIOS, and the OS just sees the resulting key presses as if the keyboard had all the buttons. Can you not find such a switch in your BIOS? Saying what vendor it is might also help someone help you.
But AOSP already is "Android without proprietary Google code", simply because "Android" means AOSP + Google Play Services + compatibility certification. It's getting increasingly more and more barebones as Google moves functionality into Google Play Services, but it is what the vast majority of third party ROMs are based on.
How they manage to then improve compatibility differs. Truly ungoogled ROMs just don't - either the app works with AOSP, or it's not welcome on the system because it would require Google services. Some use MicroG, a small open-source reimplementation that is good enough to replace the real Google Play Services for most apps (but it does communicate with Google servers similarly to the real one, so all it does from degoogling perspective is limit the amount of extra data your phone sends to Google). Then there are also ROMs that support installing the official Google Play Services and related apps. LineageOS can do that (or it can use MicroG, or just not have GPS at all), for example.
And then there is GrapheneOS which has managed to turn the Play Services into a mostly regular app that doesn't have overreaching access to the whole system and lets you configure how much data you're willing to leak to it.
Drivers also don't seem to be that big of a deal nowadays, Google's effort to simplify Android updates for OEMs has done a lot to help third party ROMs as a side effect. The biggest problem now is the various security attestation mechanisms that are available through Google Play and which Google spends a lot of time and money to convince developers to use. These are very hard / currently impossible to implement in a way that doesn't trip security checks on the affected apps - want mobile banking? Well, that's too bad because it will simply refuse to work if Google Play says your system has been tampered with. Workarounds exist, but they're not reliable over time.
I'm a bit confused about the emphasis you put in the quote... GrapheneOS is built on AOSP (the open-source part of Android), it's definitely not some OS built from ground up (look no further than the various Linux phone projects to see how terrible those are as Android replacements atm).
Technically it isn't Android, because Google owns the trademark and has some requirements for stuff that wants to call itself Android - it needs to pass a compatibility test and more importantly, include Google Play Services. But it is as much Android as any other custom ROM.
This is a very useful way to remember it, but nowadays it's better to drop the z (which immediately makes the mnemonic more forgettable, of course). tar can autodetect compression now, so tar -xf should work on anything from plain tar archives over tar.gz to more unusual compression algorithms like tar.xz or tar.bz2.
Interesting to hear that people consider Android, AOSP + proprietary bits.
Google owns the Android trademark, and they won't let you officially call any OS that doesn't meet their requirements Android. And their requirements include Gapps among other things. That means AOSP is not Android.
That requires just unlocked bootloader, not root. In the distant past before full disk encryption you could often use root to replace the bootloader with a new one that doesn't verify what OS it's booting (so you could say that rooting was part of the process of changing ROM), but nowadays it's very rare to be able to do that.
Now you either get a tool from your OEM to unlock your bootloader (and then you can flash ROMs to your heart's desire), or you're screwed.
(and i’m not sure why PG is encouraging it by boosting it)
I'm pretty sure that's just how other ActivityPub platforms see posts in Lemmy/kbin communities. There's no boosting here and @privacyguides isn't an user
Does your phone happen to be made by one of the vendors ranking high on this list? If so, that's not on Google (well, you could argue that Google could take more control over Android and force vendors not to do this, but that's another discussion - now we're talking about a fix Google made for apps evading its battery optimizations).
Because I've personally had no problem with apps like AccuBattery and GadgetBridge staying awake when set to unrestricted.
Navigate to the specific app details in settings -> Battery usage -> set to Unrestricted. There, it's off. Just like it was for the past however many years since Doze was first implemented. Or just turn off adaptive battery to disable this for all apps and enjoy your awesome battery life.
This fix is for apps that are set to optimized/restricted and are avoiding being killed.
Markaos @ Markaos @lemmy.one Posts 6Comments 217Joined 2 yr. ago
Letting you disable or limit internet access to apps would go pretty strongly against Google's interests - how would they get their ad money if half the users were running most apps offline?
Some vendors provide a way to do this (Xiaomi has an internet access toggle per app, or at least it did in the KitKat era), but it's never making its way into stock Android until Google integrates AdMob into the system.