Android 12 is live in AOSP(android-developers.googleblog.com)
android-developers.googleblog.com
Android 12 is live in AOSP
https://android-developers.googleblog.com/2021/10/android-12-is-live-in-aosp.html
141 comments
So now to "help protect private app data" they've gone from a terrible backup experience (running adb backup) to essentially no backup experience.
Unless of course you want to pay Google money and even then arguably get a subpar backup experience.
Keep in mind that you have to unlock the device AND authorize USB debugging just to get adb backup to run.
Unless of course you want to pay Google money and even then arguably get a subpar backup experience.
Keep in mind that you have to unlock the device AND authorize USB debugging just to get adb backup to run.
Instead develop a system to auto upgrade users to latest release with security patches like iOS, G is focusing on the tweaking icon/layout with a new "(im)material design".
While promoting Kotlin using Android Java (pseudo Java 8/11 subset with OpenJDK cherry picked features) as example of "Java" code.
https://www.xda-developers.com/lineageos-seedvault-open-sour...
>LineageOS adopts SeedVault as its open source backup solution [...] >For those not familiar with SeedVault, it is an open-source backup app that uses the same internal APIs as adb backup.
I hope the SeedVault people are able to circumvent that. And I hope they are willing to try, as some open source developers for some reason consider Google's user-hostile security model decisions as sacrosanct.
>LineageOS adopts SeedVault as its open source backup solution [...] >For those not familiar with SeedVault, it is an open-source backup app that uses the same internal APIs as adb backup.
I hope the SeedVault people are able to circumvent that. And I hope they are willing to try, as some open source developers for some reason consider Google's user-hostile security model decisions as sacrosanct.
Since this is LineageOS, I assume everyone is running a custom recovery. Why not use Nand backups then?
I just wonder because that's all I ever used. Just straight up bypasses any BS the OS would throw... on the same device at least.
I just wonder because that's all I ever used. Just straight up bypasses any BS the OS would throw... on the same device at least.
The advantage of app backup is that you can restore the apps to other devices. And you can selectively backup and restore subsets of apps. Nand backups do not offer that.
Furthermore your assumption might not be true in the first place: LineageOS brings its own default recovery that offers more convenient OTA updates, but does not offer Nand backups.
Also, "custom" recoveries such as TWRP might not even support some phones that are supported by LineageOS.
Yeah, I figured. I think I tried "normal" backups a few times with garbage results and gave up on it.
Just straight up reinstall everything on new machines or major OS version updates like I've been doing for nearly two decades.
Good time to reconsider a lot of apps, too.
Just straight up reinstall everything on new machines or major OS version updates like I've been doing for nearly two decades.
Good time to reconsider a lot of apps, too.
I was actually waiting for 12 rollout before installing TWRP on the 9Pro. Now I'm not so sure it's a good idea... I'm having trouble as is is making changes to system apps and Priv-App, don't need more headaches.
Looks like you are right dude. Might as well start getting used to Lineage. I'll miss the oneplus camera apps though.
Looks like you are right dude. Might as well start getting used to Lineage. I'll miss the oneplus camera apps though.
Devil's advocate- that is one interface the feds will be trying to exploit in order to extract evidence but this change makes it a little harder.
The feds will just subpoena Google or the app author.
If your device is fully encrypted, nobody can run an adb backup without authorization. This change does not protect the user; it "protects" apps.
"You will own nothing and be happy." https://www.forbes.com/sites/worldeconomicforum/2016/11/10/s...
Google keeps on stripping down AOSP more and more. Its so barebones that nothing is usable out of the box anymore. It doesn't even have a web browser these days.
All the default apps, contacts, calendar, etc haven't been updated in 8+ years.
Any new feature doesn't come to AOSP, it comes to Google Play Services.
All the default apps, contacts, calendar, etc haven't been updated in 8+ years.
Any new feature doesn't come to AOSP, it comes to Google Play Services.
The browser is an extremely fast-moving security-critical attack surface, so it’s for the best that Android WebView is maintained separately in the Chromium repository, and doesn’t need to be held back by the AOSP release schedule. It’s still open source.
https://chromium.googlesource.com/chromium/src/+/HEAD/androi...
https://chromium.googlesource.com/chromium/src/+/HEAD/androi...
It's fun that you should mention that, because assuming it is true that webview is best upgraded out-of-aosp (which I guess I kinda agree with), then why does AOSP ship with a webview?
AOSP is lacking a browser, not a webview.
AOSP is lacking a browser, not a webview.
It doesn’t:
https://android.googlesource.com/platform/external/chromium-...
“Building the Chromium-based WebView in AOSP is no longer supported or required. WebView can now be built entirely from the Chromium source code.
Docs on how to build WebView from Chromium for use in AOSP are available here: https://chromium.googlesource.com/chromium/src/+/HEAD/androi...
For questions about building WebView, please contact our mailing list: https://groups.google.com/a/chromium.org/forum/#!forum/andro...
The prebuilt APKs provided here are built from Chromium upstream sources; you should check the commit message to see the version number for a particular prebuilt. The version number is formatted like “12.0.3456.789” and matches the tag in the Chromium repository it was built from.
If you want to build your own WebView, you should generally build the latest stable version, not the version published here: newer versions have important security and stability improvements.”
https://android.googlesource.com/platform/packages/apps/Brow...
“Browser2 is a copy of the WebViewShell, a minimal test browser using WebView. The old Browser is no longer supported.
This is *not* a production quality browser and does not implement suitable security UI to be used for anything other than testing WebView. This should not be shipped in production devices, or used as the basis for implementing a real browser.
To build a full-fledged browser for AOSP, one option is to build a standalone (non-WebView-based) Chromium browser by following the instructions at: https://www.chromium.org/developers/how-tos/android-build-in... ”
If you’re going to build the WebView from an external repository, you might as well build the browser from there too.
https://android.googlesource.com/platform/external/chromium-...
“Building the Chromium-based WebView in AOSP is no longer supported or required. WebView can now be built entirely from the Chromium source code.
Docs on how to build WebView from Chromium for use in AOSP are available here: https://chromium.googlesource.com/chromium/src/+/HEAD/androi...
For questions about building WebView, please contact our mailing list: https://groups.google.com/a/chromium.org/forum/#!forum/andro...
The prebuilt APKs provided here are built from Chromium upstream sources; you should check the commit message to see the version number for a particular prebuilt. The version number is formatted like “12.0.3456.789” and matches the tag in the Chromium repository it was built from.
If you want to build your own WebView, you should generally build the latest stable version, not the version published here: newer versions have important security and stability improvements.”
https://android.googlesource.com/platform/packages/apps/Brow...
“Browser2 is a copy of the WebViewShell, a minimal test browser using WebView. The old Browser is no longer supported.
This is *not* a production quality browser and does not implement suitable security UI to be used for anything other than testing WebView. This should not be shipped in production devices, or used as the basis for implementing a real browser.
To build a full-fledged browser for AOSP, one option is to build a standalone (non-WebView-based) Chromium browser by following the instructions at: https://www.chromium.org/developers/how-tos/android-build-in... ”
If you’re going to build the WebView from an external repository, you might as well build the browser from there too.
> fast-moving
and fast-breaking, there are multiple occasions that faulty WebView updates released to the world and crashed phones. Also you'll need root to change the default WebView to something else like Bromite.
and fast-breaking, there are multiple occasions that faulty WebView updates released to the world and crashed phones. Also you'll need root to change the default WebView to something else like Bromite.
Why not just release AOSP as frequently? Then it'd be easier to push other small updates.
App store updates vs OS updates.
This distinction is not definitive. None of the normal Linux distributions makes it.
I thought OS updates require cooperation of the phone manufacturer/carriers.
Only because lazy manufacturers ships patched monstrosities that passes for software. If "Android" was responsible for booting and device drivers, or if Android was GPL for that matter, that would have ceased to be the case.
Optimism: This lets Google provide updates to users without carriers/manufacturers having to go through the process of approving Android updates for every model/carrier combination.
Cynicism: The more that Google moves into Google Play Services, the harder it is for anyone to make a usable Android device without agreeing to Google's terms.
Cynicism: The more that Google moves into Google Play Services, the harder it is for anyone to make a usable Android device without agreeing to Google's terms.
Realism: This was Google's plan from day 1 but they didn't have the oomph to do it. Android in 2040 will be 90% closed source, except for some expendable bits at the bottom, just like MacOS.
It kind of makes sense, though. First, there are plenty of open source browsers available, why should Google maintain one when the vast majority are going to opt for Chrome anyway?
Second, very few people want a contact or calendar app that exists solely on their phone. They want the synchronization they get from any alternative app, whether that's from Facebook, Google, Microsoft, or some other third party.
If you're capable of installing AOSP on a daily driver, you likely already know enough about F-Droid or other open source projects to find and install a better alternative anyway.
Lastly, I totally agree about your concern with GPS being the default for any new feature implementation. I think that allowing Google to push alternative OS builders out of the game or forcing them to implement a GPS alternative from scratch, which sucks.
Second, very few people want a contact or calendar app that exists solely on their phone. They want the synchronization they get from any alternative app, whether that's from Facebook, Google, Microsoft, or some other third party.
If you're capable of installing AOSP on a daily driver, you likely already know enough about F-Droid or other open source projects to find and install a better alternative anyway.
Lastly, I totally agree about your concern with GPS being the default for any new feature implementation. I think that allowing Google to push alternative OS builders out of the game or forcing them to implement a GPS alternative from scratch, which sucks.
Android WebView is embedded in zillions of apps, not just the standalone browser, so it would indeed suck if Google stopped maintaining it and forced apps to embed Chrome instead. Fortunately, that is not what happened—they just moved Android WebView from AOSP to the (arguably more open) Chromium repository.
> Second, very few people want a contact or calendar app that exists solely on their phone. They want the synchronization they get from any alternative app, whether that's from Facebook, Google, Microsoft, or some other third party.
AOSP calendar supports syncing with online calendars.
AOSP calendar supports syncing with online calendars.
Oh, fair enough, my bad. Even so, syncing with which calendars? Likely Google and Outlook, which means you probably still use Gmail or Outlook.
I'm not saying there's no good argument for an open-source option being available, or that one wouldn't do well, I'm just saying that I don't understand why there should be any expectation that an operating system developer should also be expected to create and update apps like those.
I'm not saying there's no good argument for an open-source option being available, or that one wouldn't do well, I'm just saying that I don't understand why there should be any expectation that an operating system developer should also be expected to create and update apps like those.
That's news to me. DAVx5 is mandatory to sync WebDAV calendars on Android.
From an app developer's point of view, the stuff shipped with AOSP is a mess that changes from version to version and from carrier to carrier and is almost impossible to develop against completely; and that's all solved with updates from google play services and external libraries.
There are many open source contacts, calendar, etc. apps. Google is so caught up maintaining its own apps that talk to its services that I don't know why anybody would want Google's own half-assed open source implementations. Even if you wanted Google to maintain open source versions of those apps, why would you want them to be updated at the cadence that AOSP is and have them be developed in AOSP's non-collaborative manner?
Sounds good to me. The less default apps the better. At this point they probably don't go further since it might cause system issues.
GrapheneOS ships a hardened Chromium fork.
Worth looking into.
Worth looking into.
Previously, I used to be excited about new OS versions coming out. Nowadays, I'm only looking for what did they break or block this time, and how much problems would it cause.
Yes, I am in the same boat here. It feels like there is always a new iOS or Android version being released which always manages to break a feature on my app and sheds months off of my life.
Same.
I was thinking about this when I first saw this announcement and realized that if AOSP was developed in the open it probably wouldn't change anything. Releasing big updates of the open source code like this feels pointless.
I was thinking about this when I first saw this announcement and realized that if AOSP was developed in the open it probably wouldn't change anything. Releasing big updates of the open source code like this feels pointless.
AOSP is practically dead, all important parts replaced by proprietary Play Services. I think it is only a matter of time before google replaces Android and Linux with Fuchsia.
This isn't remotely true. Nearly all the advertised Android 12 features are in AOSP, not Play Services. People vastly overestimate how much stuff is in Play Services.
> Releasing big updates of the open source code like this feels pointless.
Custom ROMs still benefit
Custom ROMs still benefit
It's not like you can easily update the OS in a smartphone, to begin with...
Unless it's made with a user in mind, like Librem 5 or Pinephone.
Or a Pixel
ducks
that lets you unlock and, wait for it, relock the bootloader after installing Graphene.
ducks
that lets you unlock and, wait for it, relock the bootloader after installing Graphene.
I don't like Android 12 because of bigger zoomed in 'everything'. I don't like Windows 11 for kind of similar reason, less items in context menu, less customizable taskbar, bigger zoomed in start menu.
Don't know what the f is going on with "Modern" UIs.
Don't know what the f is going on with "Modern" UIs.
I asked a Googler about this years ago when Material Design was new. They told me that the general population has a harder time processing dense information views compared with computer geeks. Many folks find devices easier to use when there's less "going on" on-screen at once. If you bump up padding and margins, you not only reduce total visible information, but also spread out your UI elements, making it easier to visually identify which part of the screen holds the information you're looking for.
So, a pocket memex, a device born for information managers, is now developed, according to what you write, for people with some allergy to information, and to alienate information managers. Because sales, of course. And what is the option for the information managers?
> They told me that the general population has a harder time processing dense information views compared with computer geeks.
The average computer geek probably has functional literacy at college level, even those that don't actually go to college or quit part way.
Meanwhile:
> According to the U.S. Department of Education, 54% of U.S. adults 16-74 years old - about 130 million people - lack proficiency in literacy, reading below the equivalent of a sixth-grade level.
The average computer geek probably has functional literacy at college level, even those that don't actually go to college or quit part way.
Meanwhile:
> According to the U.S. Department of Education, 54% of U.S. adults 16-74 years old - about 130 million people - lack proficiency in literacy, reading below the equivalent of a sixth-grade level.
It is odd that a company so focused on diversity forces everyone to adapt to the information processing capabilities of the stupid. Or maybe not odd at all.
Edit to add: the way it was explained to me, the gap isn't about education or intelligence, but simply that computer geeks have trained for years at the specific skill of interpreting dense computer screens, in a manner and degree that the general population hasn't.
It's odd that the same general population can read news papers and books. New papers are way more dense than books and they enjoy reading all of it.
How much more dense are screens than a newspaper. Even news websites try to cram in as much as they can on as little space as possible yet they are popular among the same audience. Its more about unfamiliar text on screen more than the dense text.
How much more dense are screens than a newspaper. Even news websites try to cram in as much as they can on as little space as possible yet they are popular among the same audience. Its more about unfamiliar text on screen more than the dense text.
Likely due to accessibility: Standard guidelines for Android is that all touch targets should have a 48x48dp minimum size + 8dp spacing.
https://www.bbc.co.uk/accessibility/forproducts/guides/mobil...
https://material.io/design/usability/accessibility.html#layo...
https://www.bbc.co.uk/accessibility/forproducts/guides/mobil...
https://material.io/design/usability/accessibility.html#layo...
In my experience this is actually a good thing. Many application developers designing their own UI standards often leave buttons and touch targets that are way too small to accurately touch and it annoys the hell out of me. This often happens on the web as well!
That said, I use Android's built-in UI scaling to reduce the size of icons and such that seem to have grown as phone screens became larger.
That said, I use Android's built-in UI scaling to reduce the size of icons and such that seem to have grown as phone screens became larger.
Even the big guys are guilty of too-small touch targets sometimes. I've always thought this little back button in iOS when an app links to another app is laughably tiny
https://9to5mac.com/2017/11/13/deep-link-navigation-iphone-x...
https://9to5mac.com/2017/11/13/deep-link-navigation-iphone-x...
It's important to note that the hit box for it is much larger than the visual presentation.
I'd argue that a mismatched hitbox isn't great either, but it does solve for the touchability
I'd argue that a mismatched hitbox isn't great either, but it does solve for the touchability
For Android there's a setting that can scale down the modern UIs to render more on your screens. The "display size" setting seems to fix everything for me, even the UI for some games!
If you configure the setting to be small enough many apps will detect your phone as a tablet, though, leading to some funky tablet layouts. Your mileage may vary, but for me everything works out great.
If you configure the setting to be small enough many apps will detect your phone as a tablet, though, leading to some funky tablet layouts. Your mileage may vary, but for me everything works out great.
I tried going one size down in settings and while it does make the system UI better (more space for notifications etc) the majority of apps get unusable - everything is too small and hard to read, plus UI elements are closely packed to be clickable with fat fingers.
I'm hoping that some apps adjust and start responding to the lower scale in a way that still makes it usable but maybe that can't be done and I'm stuck with the ridiculous UI.
I'm hoping that some apps adjust and start responding to the lower scale in a way that still makes it usable but maybe that can't be done and I'm stuck with the ridiculous UI.
> Don't know what the f is going on with "Modern" UIs.
I see this as a confluence of a few different things:
1. Monitors are getting higher and higher resolutions; a 4K display that's less than 27" is going to feel awfully tiny unless you start scaling things up.
2. Things have gotten more complicated over time, and the more complicated they get the more chances that something will mess up. At some point my gaming PC decided that it was going to take 30-90 seconds for the right-click context menu in Explorer to come up, and while it was waiting it would lock up Explorer. Simplification can be a good thing.
3. People designing software are getting older and have worse eyes, so larger, clearer, less noisy UIs are a godsend.
Probably some other stuff.
I see this as a confluence of a few different things:
1. Monitors are getting higher and higher resolutions; a 4K display that's less than 27" is going to feel awfully tiny unless you start scaling things up.
2. Things have gotten more complicated over time, and the more complicated they get the more chances that something will mess up. At some point my gaming PC decided that it was going to take 30-90 seconds for the right-click context menu in Explorer to come up, and while it was waiting it would lock up Explorer. Simplification can be a good thing.
3. People designing software are getting older and have worse eyes, so larger, clearer, less noisy UIs are a godsend.
Probably some other stuff.
>Monitors are getting higher and higher resolutions; a 4K display that's less than 27" is going to feel awfully tiny unless you start scaling things up.
Does this mean people who _don't_ buy 4K displays at those resolutions are going to be disadvantaged with strangely-huge UIs? (Side note: every OS I use already has display options to scale up UI 100-200+%, but not scale down less than a "normal" 100%.)
It reminds me a little bit of when Apple's retina displays first came out and nobody knew how to handle widely-different resolutions, which resulted in huge UI/icons on normal-resolution monitors and fuzzy UI/icons on high-resolution ones, for the longest time.
Does this mean people who _don't_ buy 4K displays at those resolutions are going to be disadvantaged with strangely-huge UIs? (Side note: every OS I use already has display options to scale up UI 100-200+%, but not scale down less than a "normal" 100%.)
It reminds me a little bit of when Apple's retina displays first came out and nobody knew how to handle widely-different resolutions, which resulted in huge UI/icons on normal-resolution monitors and fuzzy UI/icons on high-resolution ones, for the longest time.
> Does this mean people who _don't_ buy 4K displays at those resolutions are going to be disadvantaged with strangely-huge UIs?
My experience so far is that if your monitor is "too small" for a given app the UI will be gigantic, sometimes to the point of being unusable.
If your monitor is "too big" for a given app, the UI will be tiny, sometimes to the point of being unusable.
Because of (I guess?) the way that Windows (so far?) has handled things, I keep ending up with apps which are too large on my laptop's 1080p screen running alongside apps which are too small on my laptop's external 1440p screen.
> It reminds me a little bit of when Apple's retina displays first came out and nobody knew how to handle widely-different resolutions, which resulted in huge UI/icons on normal-resolution monitors and fuzzy UI/icons on high-resolution ones, for the longest time.
This is a great comparison; I think the difference with MacOS is that if you're doing everything "natively" on MacOS, everything "just kinda worked" a lot of the time, but if your app does any custom drawing (e.g. for toolbar buttons) everything went to hell. In contrast, there are a lot of apps on Windows which use native controls and menus and so on which do not handle scaling well at all. Possibly they're using some API that wasn't properly updated, like Win32 or GDI or who knows what else.
I even have one app, which my company makes :/, which has an odd behaviour: if you launch it when you have a 1080p primary display, and then switch to having a 1440p primary display (by plugging into a dock or monitor or whatever) the right-click menu for the system tray icon shows up at the appropriate location for a 1080p monitor - the correct distance from the top and left of the screen - which, on a 1440p display, is near the middle of the screen.
Which reminds me, I need to report that bug.
My experience so far is that if your monitor is "too small" for a given app the UI will be gigantic, sometimes to the point of being unusable.
If your monitor is "too big" for a given app, the UI will be tiny, sometimes to the point of being unusable.
Because of (I guess?) the way that Windows (so far?) has handled things, I keep ending up with apps which are too large on my laptop's 1080p screen running alongside apps which are too small on my laptop's external 1440p screen.
> It reminds me a little bit of when Apple's retina displays first came out and nobody knew how to handle widely-different resolutions, which resulted in huge UI/icons on normal-resolution monitors and fuzzy UI/icons on high-resolution ones, for the longest time.
This is a great comparison; I think the difference with MacOS is that if you're doing everything "natively" on MacOS, everything "just kinda worked" a lot of the time, but if your app does any custom drawing (e.g. for toolbar buttons) everything went to hell. In contrast, there are a lot of apps on Windows which use native controls and menus and so on which do not handle scaling well at all. Possibly they're using some API that wasn't properly updated, like Win32 or GDI or who knows what else.
I even have one app, which my company makes :/, which has an odd behaviour: if you launch it when you have a 1080p primary display, and then switch to having a 1440p primary display (by plugging into a dock or monitor or whatever) the right-click menu for the system tray icon shows up at the appropriate location for a 1080p monitor - the correct distance from the top and left of the screen - which, on a 1440p display, is near the middle of the screen.
Which reminds me, I need to report that bug.
If you account for the screen size only, even now we have more resolution the scale of elements on screen is bigger than what screen size allows for comfortable reading.
To me these UIs improvements look like "dumbing down" of UI instead. Everything UX now suggests you the action it thinks you want to perform and hide all other options. Take context menu, start menu or taskbar in Windows 11 or in Android see the drop down from top bar which use to have more options visible at the same time in previous versions.
This will surely work for anyone who is using these systems at very basic level (new users, people with accessibility needs?). For everyone else who spend their lives in these for work or hobby this dumbing is frustrating.
To me these UIs improvements look like "dumbing down" of UI instead. Everything UX now suggests you the action it thinks you want to perform and hide all other options. Take context menu, start menu or taskbar in Windows 11 or in Android see the drop down from top bar which use to have more options visible at the same time in previous versions.
This will surely work for anyone who is using these systems at very basic level (new users, people with accessibility needs?). For everyone else who spend their lives in these for work or hobby this dumbing is frustrating.
It's getting bad again on MacOS. Big Sur made window title bars vastly bigger. Using my new mini on a 1080P monitor is pain. I really hate that no one implements a 75% scaling option for MacOS or Windows.
Saddest part is I have a replacement 1440P monitor showing up later in the week since I had to drag mine to work and it doesn't even help all that much. Macs in stores all have 2-5K resolution screens now ruining things for budget monitor folks with cheap Mac Minis.
Saddest part is I have a replacement 1440P monitor showing up later in the week since I had to drag mine to work and it doesn't even help all that much. Macs in stores all have 2-5K resolution screens now ruining things for budget monitor folks with cheap Mac Minis.
New mini? I had a mini and two Mac Pros in a job four years ago and when ARD launched in 1080p the screen was unmanagably cramped and everything was huge.
As someone who used 768p 15" laptop until late 2019, yes, everyone else has to deal with bs huge menus. Oh the number of webpages that would have you scroll horizontally, often with white bar on both sides... The day I upgraded to 1080p I could feel a sense of joy in being able to see the web as it was designed. And now every web developer is beginning to develop on 27" (or less) 4K displays and the target is shifting for less fortunate yet again.
> 3. People designing software are getting older and have worse eyes, so larger, clearer, less noisy UIs are a godsend.
"Modern" UIs most often are anything but clear and less noisy. Part of what made the Windows 95 design so strong was that UI elements were separated by visible lines, you exactly knew what the touchbox of any element was, the behavior and look of UI elements, menus and icons were generally consistent across applications...
"Modern" UIs most often are anything but clear and less noisy. Part of what made the Windows 95 design so strong was that UI elements were separated by visible lines, you exactly knew what the touchbox of any element was, the behavior and look of UI elements, menus and icons were generally consistent across applications...
I think that's the worst part of the new Firefox UI. Firefox got rid of the defined, rectangular tabs using a colored background with lines between them. Now it's white rounded rectangles floating in a light-gray background with no other visible distinction. Even with perfect eyes, it was hard to tell what was going on without taking a moment to really focus on it.
It clashes heavily with the container tabs add on as well. The new UI adds a coloured bar on top of a container tab, which I always mistake as an open tab since it's far more visible than the actual open tab indicator
Desktop? Miss me with that shit, I still stubbornly click "not now" whenever I unlock my laptop :D
There are some tweaks out there which patch the CSS to bring stuff slightly closer to the original style.
Oh, I've managed to get it looking basically exactly like Firefox 90 again for me, but it's still a hassle to have to inject custom CSS on every machine to get an easily-usable interface. And I feel bad for people like my elderly dad who don't have that know-how and will have to just live with Mozilla's indifference to accessibility.
What's going on is that UI designers keep thinking people care more about balancing negative and positive space than seeing all the information they want. At the same time, UI customizability has gone out of fashion. So we get lowest common denominator mediocrity that looks good in a slide show but is awful to use for serious work.
No company should have full time UI designers on staff. Eventually they look for reasons to justify themselves, and start ruining things that were perfectly fine.
No company should have full time UI designers on staff. Eventually they look for reasons to justify themselves, and start ruining things that were perfectly fine.
Turn down the UI scaling. That works well enough for me. I also run Nova7 as my launcher, so I can control icon and text sizes independent of the UI scaling.
Scaling UI doesn't increase the number of buttons in the top at drop down visible at the same time. They use to be 9 before Android 10 I think. In Android 12 they are even bigger. Scaling down won't fix it. I already use it scaled BTW.
For every new release of android there is only one thing I care about, how will this affect termux?
So I did a google and looks promising ( https://www.reddit.com/r/termux/comments/nyayhq/comment/h1j9... ).
So I did a google and looks promising ( https://www.reddit.com/r/termux/comments/nyayhq/comment/h1j9... ).
Termux folks need to accept Android main APIs are Java based and POSIX is not an official NDK API.
https://developer.android.com/ndk/guides/stable_apis
Whatever cannot be done with ISO C and ISO C++ standard libraries, GL ES or Vulkan for the UI, needs to drop into JNI or Android IPC, period.
https://developer.android.com/ndk/guides/stable_apis
Whatever cannot be done with ISO C and ISO C++ standard libraries, GL ES or Vulkan for the UI, needs to drop into JNI or Android IPC, period.
I just want to be able to run Python scripts and whatnot on my phone; I don't care much about how it's implemented. I'm sure it's possible to have this without compromising security. As far as I know, the Android sandbox already provides pretty great protection against any programs running inside Termux, so there's not much reason to block exec()? It would at least be nice if they made W^X exec() into a permission (probably not toggleable from the Settings UI, perhaps only grantable through `adb shell pm grant`, if they want to make sure only powerusers can do this). For example, some poweruser apps like Tasker can be granted "WRITE_SECURE_SETTINGS" permission through adb to unlock more features. This permission is very powerful so it can't be granted through the Settings UI.
Using adb is a feature only in developer mode, plugged into SDK tools.
You can enjoy PyDroid for the time being,
https://play.google.com/store/apps/details?id=ru.iiec.pydroi...
But it might not be around for long,
https://www.theregister.com/2021/07/29/google_play_python_ja...
You can enjoy PyDroid for the time being,
https://play.google.com/store/apps/details?id=ru.iiec.pydroi...
But it might not be around for long,
https://www.theregister.com/2021/07/29/google_play_python_ja...
> Using adb is a feature only in developer mode, plugged into SDK tools.
I'm aware. The difficulty in this process would act as a filter ensuring only powerusers can do it. It would certainly not be ideal to have to do this just to use Termux, but if Google wants to eventually enforce W^X exec(), it would be better than nothing.
I'm honestly curious as to what the security implications of allowing exec() in writable directories really is. For example, GrapheneOS' top priority is security and it hardens the Android sandbox even beyond AOSP, and yet it still supports Termux (and I doubt its users would accept if it dropped support for this, even if in exchange for a little extra security).
If anyone knows about this, I would appreciate your input.
I'm aware. The difficulty in this process would act as a filter ensuring only powerusers can do it. It would certainly not be ideal to have to do this just to use Termux, but if Google wants to eventually enforce W^X exec(), it would be better than nothing.
I'm honestly curious as to what the security implications of allowing exec() in writable directories really is. For example, GrapheneOS' top priority is security and it hardens the Android sandbox even beyond AOSP, and yet it still supports Termux (and I doubt its users would accept if it dropped support for this, even if in exchange for a little extra security).
If anyone knows about this, I would appreciate your input.
> It would at least be nice if they made W^X exec() into a permission
W^X is what Android is pushing people towards, there's no reason for a permission to guard what's recommended.
And it doesn't restrict any useful behavior. It does require some design burden to do properly, though, which not everyone is willing to do. But eg Chrome & Firefox have no issues with their JavaScript JITs that still comply with W^X.
W^X is what Android is pushing people towards, there's no reason for a permission to guard what's recommended.
And it doesn't restrict any useful behavior. It does require some design burden to do properly, though, which not everyone is willing to do. But eg Chrome & Firefox have no issues with their JavaScript JITs that still comply with W^X.
I meant a permission to circumvent the W^X restriction.
> And it doesn't restrict any useful behavior. It does require some design burden to do properly, though, which not everyone is willing to do.
Do you know of any alternative approach to the gross APK packaging one? I would say it definitely restricts "useful behavior", unless you think Termux would be just as useful after API 29 compatibility were implemented (and I would disagree).
Besides, when thinking about implementing a security feature, the question "does this restrict behavior?" is important (and I think it does in this case), but not quite as relevant as the question "what actual extra security does this provide?", and I'm not quite sure how much extra security this provides.
Could someone provide a realistic attack scenario?
> And it doesn't restrict any useful behavior. It does require some design burden to do properly, though, which not everyone is willing to do.
Do you know of any alternative approach to the gross APK packaging one? I would say it definitely restricts "useful behavior", unless you think Termux would be just as useful after API 29 compatibility were implemented (and I would disagree).
Besides, when thinking about implementing a security feature, the question "does this restrict behavior?" is important (and I think it does in this case), but not quite as relevant as the question "what actual extra security does this provide?", and I'm not quite sure how much extra security this provides.
Could someone provide a realistic attack scenario?
Me too, haha. I like the new UI and privacy controls, but this is always the most important consideration.
By the way, as far as I know, Termux (at least as we know it) is for sure eventually doomed, which is really sad. Here's a brief explanation for those uninitiated:
* Android 10 introduced a restriction that apps targeting API version 29+ can no longer invoke exec() on files within the app's home directory, which breaks Termux [1].
* An app can target any API version. There is a hardcoded "min_supported_target_sdk" in the Android source code (23 as of Android 12) [2], but as of now targeting a lower version only produces a warning, and it will likely take quite a long time before it reaches 29 anyway [3]. The main problem is that the Play Store won't allow new app updates targeting <29. For now, the Play Store Termux build is very out of date and it's recommended to get Termux from F-Droid. But for some reason, the developer of Termux has decided that they want to make Termux API 29 compatible [4]. (Perhaps to ensure long-term compatibility if the "min_supported_target_sdk" ever increases past 28 AND starts to actually be enforced, or maybe just because they want to distribute Termux in the Play Store, even though most of its users would be perfectly comfortable getting it from F-Droid?)
* Making Termux API 29 compatible will make it a lot less fun and a lot less practical to use. All executables will have to be distributed inside separate APK files which must be individually installed, since exec() can now only be called on files in the read-only /data/app directory [5]. Say goodbye to `apt install <name>`.
* Google continues to further restrict the OS in ways that break certain functionality within Termux.
* Termux still works mostly normally for now in Android 10 and 11 (and 12, it seems), but its developer is already at work on the weird APK packaging system.
[1] https://github.com/termux/termux-packages/wiki/Termux-and-An...
[2] https://android.googlesource.com/platform/prebuilts/fullsdk/...
[3] https://github.com/termux/termux-app/issues/1072#issuecommen...
[4] https://github.com/termux/termux-app/issues/1072#issuecommen...
[5] https://github.com/termux/termux-app/issues/1072#issuecommen...
=== EDIT ===
According to the README, the current plan is actually to continue targeting API 28 for now:
> There is currently no work being done to solve android 10 issues and working updates will not be resumed on Google Play Store any time soon. We will continue targeting sdk 28 for now.
They are looking for contributors to help make an API 29 compatible version though:
> @termux is looking for Termux Application maintainers for implementing new features, fixing bugs and reviewing pull requests since the current one (@fornwall) is inactive. Issue https://github.com/termux/termux-app/issues/1072 needs extra attention.
https://github.com/termux/termux-app/blob/master/README.md#g...
By the way, as far as I know, Termux (at least as we know it) is for sure eventually doomed, which is really sad. Here's a brief explanation for those uninitiated:
* Android 10 introduced a restriction that apps targeting API version 29+ can no longer invoke exec() on files within the app's home directory, which breaks Termux [1].
* An app can target any API version. There is a hardcoded "min_supported_target_sdk" in the Android source code (23 as of Android 12) [2], but as of now targeting a lower version only produces a warning, and it will likely take quite a long time before it reaches 29 anyway [3]. The main problem is that the Play Store won't allow new app updates targeting <29. For now, the Play Store Termux build is very out of date and it's recommended to get Termux from F-Droid. But for some reason, the developer of Termux has decided that they want to make Termux API 29 compatible [4]. (Perhaps to ensure long-term compatibility if the "min_supported_target_sdk" ever increases past 28 AND starts to actually be enforced, or maybe just because they want to distribute Termux in the Play Store, even though most of its users would be perfectly comfortable getting it from F-Droid?)
* Making Termux API 29 compatible will make it a lot less fun and a lot less practical to use. All executables will have to be distributed inside separate APK files which must be individually installed, since exec() can now only be called on files in the read-only /data/app directory [5]. Say goodbye to `apt install <name>`.
* Google continues to further restrict the OS in ways that break certain functionality within Termux.
* Termux still works mostly normally for now in Android 10 and 11 (and 12, it seems), but its developer is already at work on the weird APK packaging system.
[1] https://github.com/termux/termux-packages/wiki/Termux-and-An...
[2] https://android.googlesource.com/platform/prebuilts/fullsdk/...
[3] https://github.com/termux/termux-app/issues/1072#issuecommen...
[4] https://github.com/termux/termux-app/issues/1072#issuecommen...
[5] https://github.com/termux/termux-app/issues/1072#issuecommen...
=== EDIT ===
According to the README, the current plan is actually to continue targeting API 28 for now:
> There is currently no work being done to solve android 10 issues and working updates will not be resumed on Google Play Store any time soon. We will continue targeting sdk 28 for now.
They are looking for contributors to help make an API 29 compatible version though:
> @termux is looking for Termux Application maintainers for implementing new features, fixing bugs and reviewing pull requests since the current one (@fornwall) is inactive. Issue https://github.com/termux/termux-app/issues/1072 needs extra attention.
https://github.com/termux/termux-app/blob/master/README.md#g...
Good luck with that plan,
https://developer.android.com/distribute/best-practices/deve...
> Starting in November 2021, app updates will be required to target API level 30 or above and adjust for behavioral changes in Android 11. Existing apps that are not receiving updates are unaffected and can continue to be downloaded from the Play Store. Wear OS apps must continue to target API level 28 or higher.
Android is not a POSIX OS, apis like exec() where never part of the public APIs, time to embrace the Java ways of the platform.
https://developer.android.com/ndk/guides/stable_apis#c_libra...
https://developer.android.com/distribute/best-practices/deve...
> Starting in November 2021, app updates will be required to target API level 30 or above and adjust for behavioral changes in Android 11. Existing apps that are not receiving updates are unaffected and can continue to be downloaded from the Play Store. Wear OS apps must continue to target API level 28 or higher.
Android is not a POSIX OS, apis like exec() where never part of the public APIs, time to embrace the Java ways of the platform.
https://developer.android.com/ndk/guides/stable_apis#c_libra...
This is Play Store policy, not Android policy. As I said, the Android OS currently doesn't enforce the minimum API level, and this probably won't become a problem for a long time, as long as you are distributing outside the Play Store (e.g. through F-Droid).
That isn't the Android version that most people get to use.
When I say "Android OS" here, I don't mean AOSP, I mean most (or all) manufacturer-customized Android ROMs, including Samsung, Pixel, etc. I don't think any of them further restrict this.
Even if it's technically possible to work around it, it would be a ridiculous amount of effort for not particularly good reasons.
I don't know how to feel about the introduction of splash screens for all apps.
I imagine they were needed to disguise some initial rendering of the app, but as a user I really really don't want to see splash screens when opening an app on a mobile device...
I imagine they were needed to disguise some initial rendering of the app, but as a user I really really don't want to see splash screens when opening an app on a mobile device...
It used to be against UX guidelines in Android but if the app startup cannot be any faster I don't mind a splash screen. Basically anything that indicates the phone has not frozen up even if it ends up taking a quarter second longer.
What I find truly jarring is when I tap on a UI element and it responds after 2 seconds. I'd take splash screen and slow animation over that anyday.
What I find truly jarring is when I tap on a UI element and it responds after 2 seconds. I'd take splash screen and slow animation over that anyday.
My theory is that this is because of Flutter apps that sometimes struggle to initialize quickly from a cold start. They had (have?) this issue on iOS and I've seen some of them have the problem on Android too, something to do with shaders if I recall correctly.
I hate seeing splash screens. When I encounter them, I see that as a sign that the developers weren't capable enough or didn't care enough to make their app start up quickly. I'm fine with games showing splash screens as they unpack resources and load shaders, but a chat app or a calendar shouldn't have to show me a "look at me I'm loading" screen.
I hate seeing splash screens. When I encounter them, I see that as a sign that the developers weren't capable enough or didn't care enough to make their app start up quickly. I'm fine with games showing splash screens as they unpack resources and load shaders, but a chat app or a calendar shouldn't have to show me a "look at me I'm loading" screen.
I hate this when in visiting "Outlook.com" and especially when I go from mail to calendar.
> Notification UI updates - We also refreshed notification designs to make them more modern and useful.
Please.... please just for a couple of years can we stop doing this? Why does my notification UI have to change so frequently?
Please.... please just for a couple of years can we stop doing this? Why does my notification UI have to change so frequently?
When you have enough designers and "UX experts" on staff to create an entire OS + productivity suite's design every year, you're going to get an entire OS + productivity suite's design every year.
Material You is just gorgeous. I love the pastel color schemes it makes, and the shapes are very refreshing compared to what has been "in" for the last few years IMO
YMMV but my gmail and dialer just recently got much uglier with blueish tones. Feels like Material UI was great looking around android 5.0 and goes downhill ever since.
IMO Material only became good around Android 7. When Android 5 was still around, the boilerplate components were all way too big and the information density was incredibly low compared to Holo. Apps were tweaked and around Android 7 did I find them to be actually usable again.
Google Calendar had this issue the worst if I recall. There were these gaudy, colourful images everywhere with cards sliding around and big, friendly buttons all over the place. The design looked pretty great during a quick presentation, but in practice I found it very hard to use the "stream" view calendar properly when I could see two or three events at most without scrolling.
Google Calendar had this issue the worst if I recall. There were these gaudy, colourful images everywhere with cards sliding around and big, friendly buttons all over the place. The design looked pretty great during a quick presentation, but in practice I found it very hard to use the "stream" view calendar properly when I could see two or three events at most without scrolling.
Sure, they did have a shortage of components, but the existing components were simple, clear, attractive. No ugly oval floating buttons or chiseled navbars hugging the FAB.
Currently, the notes app is a good example of such uglyfication: what was previously a simple attractive app now sports a horrendous navbar with ugly squarerounded plus button of unclear color. Phew.
Currently, the notes app is a good example of such uglyfication: what was previously a simple attractive app now sports a horrendous navbar with ugly squarerounded plus button of unclear color. Phew.
I think android you looks liem fisher-price ui. Like the kind of OS UI you'd see for small children.
Sadly, the update to Pixel phones comes in the next few weeks they say.
https://9to5google.com/2021/10/04/android-12-aosp/
https://9to5google.com/2021/10/04/android-12-aosp/
Are you sad that you can review the source code before the OS gets installed on your device?
Can't verify the compiled source is what gets delivered to your Pixel device, though.
It's important to note that, while it is true that you can't verify no changes have been made to the AOSP sources on the stock Pixel ROM, it's irrelevant because the Pixel ROM doesn't even claim to be AOSP -- it's a Google-flavored version of AOSP with the following "bonus features":
* Google cloud-synced replacements for the more barebones (but at least local) stock AOSP apps (which can be disabled, but not fully uninstalled): Google Calendar (instead of AOSP Calendar), Google Photos (AOSP Gallery), Gmail (AOSP Email), Google Keyboard (Android Keyboard), etc
* A few Pixel-exclusive Google apps not (yet) available on other Android phones: Pixel Launcher, Audio Recorder, etc
* The standard suite of Google system apps present even on most non-Pixel phones, like Play Store and Play Services, with special higher privileges that aren't available to other apps and can't be revoked
* The only option for system backup is to use Google Drive
It infuriates me that almost none of the stock apps (aside from Google Photos and maybe Gmail) allow you to use them without a Google account, by the way. On a Google Pixel, the stock note-taking app is Google Keep Notes, so you can't do something as simple as write a note locally, without sending it to Google servers, unless you install a third-party note-taking app. What the fuck.
* Google cloud-synced replacements for the more barebones (but at least local) stock AOSP apps (which can be disabled, but not fully uninstalled): Google Calendar (instead of AOSP Calendar), Google Photos (AOSP Gallery), Gmail (AOSP Email), Google Keyboard (Android Keyboard), etc
* A few Pixel-exclusive Google apps not (yet) available on other Android phones: Pixel Launcher, Audio Recorder, etc
* The standard suite of Google system apps present even on most non-Pixel phones, like Play Store and Play Services, with special higher privileges that aren't available to other apps and can't be revoked
* The only option for system backup is to use Google Drive
It infuriates me that almost none of the stock apps (aside from Google Photos and maybe Gmail) allow you to use them without a Google account, by the way. On a Google Pixel, the stock note-taking app is Google Keep Notes, so you can't do something as simple as write a note locally, without sending it to Google servers, unless you install a third-party note-taking app. What the fuck.
Still better than what Apple offers.
As an embedded linux developer, what Android brings is an unified UI(after all those x-windows variants plus Qt GUI). As long as the below list remains to be OSS, Android can be used in many non-realtime devices that need a GUI(with/without touchscreen):
* the linux kernel
* the ART(java jvm) which most GUI apps depending on
* base code to support the multimedia stack(video/audio)
* NDK(c/c++)
Gonna predict some of the more controversial changes:
- Removing GPay/DeviceControls from power menu
- The new overscroll stretch animation
- The new lockscreen clock (very hit and miss)
- The new Material You widgets
Any I missed?
- Removing GPay/DeviceControls from power menu
- The new overscroll stretch animation
- The new lockscreen clock (very hit and miss)
- The new Material You widgets
Any I missed?
Web intent resolution change is probably going to create a lot of drama when someone actually notices it.
What do you mean by that?
Something is mentioned here: https://commonsware.com/blog/2021/04/23/random-musings-andro... – I think it was something stupid like ACTION_VIEW only offering your default browser plus any apps explicitly whitelisted by the respective domain owner, so any third-party apps are out and need to be manually launched. (Maybe you could set a helper app as your default browser to work around this, but if I really remember the above correctly, it's still rather grrrrr...)
In addition to other regressions mentioned here, Android 12 also removes the ability to set a custom "share" screen (akin to Sharedr).
I don't like Android 12 because of bigger zoomed in 'everything'. I don't like Windows 11 for kind of similar reason, less items in context menu, less customizable taskbar, bigger zoomed in start menu.
Don't know what the f* is going on with "Modern" UIs.
Don't know what the f* is going on with "Modern" UIs.
What I usually do these days is change the display size/DPI.
Settings > Display > Display Size set it to Small or Smaller.
Wasn't wireguard supposed to be released natively in this version? I didn't see anything in the release notes about this.
[deleted]
It took me way too long to realize the other-device-battery-indicators weren't four days from four different calendars (which, before I realized what they really were, I figured you could tap to go see the full calendar)
Is there any decent Android (non Chinese) device that is free of Google privacy invading software ?
You can buy a pixel device and flash it to AOSP here: https://flash.android.com/
Install a launcher of your choice and be on your way: https://www.tomsguide.com/uk/round-up/best-android-launchers
Install a launcher of your choice and be on your way: https://www.tomsguide.com/uk/round-up/best-android-launchers
Is there any notable difference between flashing a GSI vs flashing AOSP from source or is the latter just done to ensure a degree of control over what one puts on one's device?
No difference except you did it from source and spent the build time yourself.
Ironically the best option if you want a secure, private phone is usually to buy a Google Pixel phone, then install GrapheneOS on it. Technically you can use plain old AOSP, but GrapheneOS is probably the better option because:
* You can re-lock the bootloader after installing it for security (unlike AOSP which is not signed by Google).
* It has additional security/privacy protections on top of AOSP, like the ability to disable the "Internet" permission for individual apps.
* It supports Play Services in a secure sandbox to allow for much greater app compatibility (since most Android apps in the Play Store require Play Services). The only way to add support for these apps to AOSP is to install the "Google privacy invading software" you mentioned on top of it, and grant it special privileges over your phone (otherwise it will refuse to run). While the Play Services sandbox feature of GrapheneOS requires installing Play Services on your phone, it not granted any special permissions; it's treated just like any other app. GrapheneOS simply lies to Play Services, telling it that it has special permissions when it actually doesn't. Pretty clever solution! And if you're not comfortable even with this low risk version of Play Services, you can simply choose to stick to F-Droid, but it's nice to have the option if you need it. You can even install sandboxed Play Services in an isolated profile to keep it separate from your main apps if you want.
https://grapheneos.org/usage#sandboxed-play-services
Edit: AOSP also has no backup/restore options, while GrapheneOS has Seedvault.
I also found a fun video that provides a glimpse at what raw AOSP really looks like: https://www.youtube.com/watch?v=ZWaAilxX28g&t=306s
It doesn't even have a setup wizard.
* You can re-lock the bootloader after installing it for security (unlike AOSP which is not signed by Google).
* It has additional security/privacy protections on top of AOSP, like the ability to disable the "Internet" permission for individual apps.
* It supports Play Services in a secure sandbox to allow for much greater app compatibility (since most Android apps in the Play Store require Play Services). The only way to add support for these apps to AOSP is to install the "Google privacy invading software" you mentioned on top of it, and grant it special privileges over your phone (otherwise it will refuse to run). While the Play Services sandbox feature of GrapheneOS requires installing Play Services on your phone, it not granted any special permissions; it's treated just like any other app. GrapheneOS simply lies to Play Services, telling it that it has special permissions when it actually doesn't. Pretty clever solution! And if you're not comfortable even with this low risk version of Play Services, you can simply choose to stick to F-Droid, but it's nice to have the option if you need it. You can even install sandboxed Play Services in an isolated profile to keep it separate from your main apps if you want.
https://grapheneos.org/usage#sandboxed-play-services
Edit: AOSP also has no backup/restore options, while GrapheneOS has Seedvault.
I also found a fun video that provides a glimpse at what raw AOSP really looks like: https://www.youtube.com/watch?v=ZWaAilxX28g&t=306s
It doesn't even have a setup wizard.
CalyxOS, or GrapheneOS, flashed to a Pixel device will be a far better degoogled experience than plain AOSP. Though I don't think CalyxOS's chromium webview is fully degoogled, iirc. Something about too many apps breaking.
Very happy about the speed and privacy improvements. I'm excited to install this.
This is only tangentially related but... Anyone else cringe / feel and overwhelming desire to turn off any video like the first one in this article (#AndroidDevSummit: tune in October 27-28!) where someone speaks in that excessively excited and optimistic voice? It is as cliché and gag inducing to me as the infomercial voiceover guy explaining how something simple thing is a disaster and how they have now solved it.
I can't turn that shit off fast enough.
Also, I really like Keri Byron from Myth busters, etc. This is not a complaint about a personality or whatever. Just this delivery that seems to be everywhere in tech sales pitches and time shares.
I can't turn that shit off fast enough.
Also, I really like Keri Byron from Myth busters, etc. This is not a complaint about a personality or whatever. Just this delivery that seems to be everywhere in tech sales pitches and time shares.
Agree and feel the same way with presentations like this. Also, I dislike how so many tech presentations have such a childish tone or silliness to them all the time, instead of just presenting information to adults as adults in a normal way. It's very distracting in my opinion.
For years and years I watched Kari Byron dubbed in my native language. And the dubbers are mostly really good over there, great actors. Today I got to hear her real voice for the first time, and it was... weird. I feel some kind of immersion has been broken. There are quite a few shows I can't watch in English due to the real actors (or English dubbers) being worse than the dubbers of my countries. I'll add Kari to the list.
Other than that, she's great! I'm a huge fan.
Edit: it's Kari.
Other than that, she's great! I'm a huge fan.
Edit: it's Kari.
I also find that style annoying, to the point that I wonder why it's even in use. I always thought it was an American thing, given it's barely present in my country, and when it's used it sounds ridiculous to most people.
I agree. I also like Kari so it's not her. I dig tech stuff, I just don't need a cheerleader.
I didn’t think it was at all excessively excited and optimistic. Just presented with a smile like any host I expect to do. I thought it was fine. Maybe it’s cultural.
[deleted]
Windows 11
macOS 11
Debian 11
Android 11
this is the only reason android 12 was released
macOS 11
Debian 11
Android 11
this is the only reason android 12 was released
I'm pretty sure a new version of Android comes out every year. If Windows 11 wasn't announced, do you think they'd hold off for a while?
https://en.m.wikipedia.org/wiki/Android_version_history#Over...
https://en.m.wikipedia.org/wiki/Android_version_history#Over...
Android 8.0 Oreo
Android 9 Pie
Android 10
Android 11
... Are probably the reasons android 12 was released
Android 9 Pie
Android 10
Android 11
... Are probably the reasons android 12 was released
iOS 15
Ubuntu 21.04
Opensuse 15.3
FreeBSD 13
Be careful you don't cherry pick your data points
Ubuntu 21.04
Opensuse 15.3
FreeBSD 13
Be careful you don't cherry pick your data points
iphone 11. checkmate
... Pixel 6? We are discussing OSs, not hardware.
2021. 21: 2 times 0 is 0, so nothing. 21: double 1, so 11.
Jigo.
Jigo.
This could all be an elaborate set up for android 13.
It isn't "app data", it is my data! This is the straw that made me switch to LineageOS, my phone shouldn't prevent me from accessing my data!