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.
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.
But graphene does not let you do anything more than AOSP, specifically it does not trust you enough to let you have root while using a locked bootloader.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.”
“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.
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.
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.
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.
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?
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...
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.
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 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.
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 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.
> 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...
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
>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.
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.
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.
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.
> 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.
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.
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
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.
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.
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.
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.
> 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.
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.
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?
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.
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...)
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.
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.
> 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.
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).
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.
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.
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.
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?
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?
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.
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.
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.
> To help protect private app data, Android 12 changes the default behavior of the adb backup command. For apps that target Android 12 (API level 31) or higher, when a user runs the adb backup command, app data is excluded from any other system data that is exported from the device.
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!
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.
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".
>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.
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.
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++)
There are many devices can use Android for applications that have no need for google play store apps at all.
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)
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.
140 comments
[ 96.9 ms ] story [ 4667 ms ] threadI 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.
Custom ROMs still benefit
ducks
that lets you unlock and, wait for it, relock the bootloader after installing Graphene.
https://9to5google.com/2021/10/04/android-12-aosp/
* 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.
macOS 11
Debian 11
Android 11
this is the only reason android 12 was released
https://en.m.wikipedia.org/wiki/Android_version_history#Over...
Ubuntu 21.04
Opensuse 15.3
FreeBSD 13
Be careful you don't cherry pick your data points
Jigo.
Android 9 Pie
Android 10
Android 11
... Are probably the reasons android 12 was released
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.
Other than that, she's great! I'm a huge fan.
Edit: it's Kari.
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.
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.
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.
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.
AOSP calendar supports syncing with online calendars.
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.
https://chromium.googlesource.com/chromium/src/+/HEAD/androi...
AOSP is lacking a browser, not a webview.
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.
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.
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.
Worth looking into.
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...
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.
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.
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 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.
"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...
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.
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.
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.
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.
https://www.bbc.co.uk/accessibility/forproducts/guides/mobil...
https://material.io/design/usability/accessibility.html#layo...
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.
https://9to5mac.com/2017/11/13/deep-link-navigation-iphone-x...
I'd argue that a mismatched hitbox isn't great either, but it does solve for the touchability
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'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.
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.
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.
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.
- 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?
So I did a google and looks promising ( https://www.reddit.com/r/termux/comments/nyayhq/comment/h1j9... ).
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://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/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.
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...
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.
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.
> 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?
Install a launcher of your choice and be on your way: https://www.tomsguide.com/uk/round-up/best-android-launchers
https://nitter.mailstation.de/DanielMicay
* 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.
Please.... please just for a couple of years can we stop doing this? Why does my notification UI have to change so frequently?
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!
Looks like you are right dude. Might as well start getting used to Lineage. I'll miss the oneplus camera apps though.
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.
>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.
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.
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.