Some people are willing to make that sacrifice because their limited feature set doesn't impede on their day-to-day use. I know quite a few people who use their phone for nothing but texting, a camera, and two factor auth.

Hell, I, who would be considered a power user, spend 99% of the time on my phone browsing the web, Reddit, some Facebook, using a calculator, or taking photos. Most of my computing is done on an actual computer because the form factor of a phone just doesn't satisfy my needs.

The reason why I'm on Android instead of a iOS 1200 euro Apple device with fancy sensors is because I don't give a shit about making pictures or videos.

For me, that is also why my phone was 200€

Exactly, Android has phones in the under 400 euro range.

I'm just not a cool person flashing expensive iPhone taking Instagram pictures. Drop the camera suite and image processing and you can cut half the cost of a smartphone!

What I actually want is mediocre camera, high build quality, small form factor. But I’m pretty sure there are not enough of us, so I have to go with medium cam, build, and size.

To test your hypothesis I just googled the articles Pixel 2 vs it's competitor iPhone 8. In both the top two search results the Pixel (narrowly) bested the iPhone, so looks like maybe a bit of rose-tinted brand-owners perspective in your case?

When I spoke of inferior experiences, I was referring to the Pine Phone, not the Pixel 2. I'm sorry that wasn't clear!

That said, the iPhone 8 is still supported by Apple (probably for the last year), while the Pixel 2, like the Pixels 3, 4, and 5, are no longer supported by Google. This likely doesn't matter to someone not running standard Google-supplied AndroidOS, though!

My use of the closed-source iPhone is not solely based on feature quality, and I've got no illusions that every feature is the best in class.

P.S. Just before clicking the reply button, I decided to do the search myself, curious. The iPhone 8 was a weird model; that was the year they released both the iPhone 8 and the iPhone X, because (IMO) they lacked the courage to switch things up in their flagship product so much in one year. (Okay, and maybe also supply issues?) Still, when I DDG'd "pixel 2 iphone 8", I got results[0] that seem to not be the same as yours. The first doesn't really make any determination, the second is mealy-mouthed but seems to give an edge to Pixel 2 based primarily on price ("the Pixel 2 is a better value, starting out at about $50 and £70 cheaper than the iPhone 8" vs "you'll actually get more bang for your buck with the iPhone 8"), and the third, well, it's right in the title: "iPhone 8 vs. Pixel 2: Why Apple Beats Google." So I don't know, I bought an iPhone X that year rather than an iPhone 8, and just replaced that with an iPhone 14 Pro this year after five years of faithful service. But choosing a 2017 phone today, either one, while very clearly a step up from Pinephone for all the of the reasons mentioned in the article, maybe still reflects a but of compromise in service of wanting to run LineageOS. In 2017, was photo quality the same when running LineageOS rather than Google's own camera software? Maybe it was after that they started to apply more and more AI to the photo-taking process, I'm not sure.

0. https://www.techradar.com/news/google-pixel-2-vs-iphone-8 https://www.cnet.com/tech/mobile/iphone-8-vs-pixel-2-phone-c... https://www.tomsguide.com/us/iphone-8-vs-pixel-2,review-4779...

> This likely doesn't matter to someone not running standard Google-supplied AndroidOS, though!

It does a bit, actually. While we get many updates through generic Android, some are vendor patches which stop after support stops.

The pixel 4 is only losing support this month. Pixel 5 is supported til Oct 2023, and 5a til Aug 2024. Pixel 6 gets feature updates til Oct 2024 and security updates til Oct 2026.

So you realize how bad it is that a phone made by Google introduced in November of 2019 is losing support in 3 years? iOS 16 supports the iPhone 8/iPhone 10 from 2017 and the iPhone 5s from 2013 just got a security update August of this year.

It is indeed, terrible. That's probably why people want a phone running Linux, since it supports hardware even longer than the XNU kernel does.

And now fast forward 5 years and the iPhone 8 is still getting full OS updates and the Pixel 2 stopped getting basic security patches 2 years ago.

At this point I think I qualify as a career Android developer (did other stuff but just a lot of time on Android) and my joking reply to anyone who asks why I use an iPhone is:

> I'll switch back when Android can handle a screen rotation without blanking the screen.

The thing is, the fact there's no smooth rotation isn't literally a blocker, but it's what such a subtle thing represents: Android apps are still living with the complexity of a situation that showed up because of the limitations of the 256 MB of RAM the Android G1 had in 2008.

-

They're still doing this messy state restoration stuff where the OS essentially has to kill part of your app to support a basic rotation, they never went back and fixed it as phones matured, bad configuration change handling easily causes hundreds of thousands of crashes a day for end users, constantly throws a wrench in development that Google has had to invent many different catcher's mitts for, drains resources that would be better used on improving the user-facing functionality of these apps.

And this isn't the only feature like that. There are so many basic sharp edges of the OS UX-wise that will just seemingly never get fixed, and even if were fixed tomorrow, it'd be at least 6 years before those improvements represented even 90% of the Android userbase (something iOS tends to achieve within 12 months...)

[and before the nitpickers show up, yes you can override configuration changes and manage that for your own app... no it doesn't scale for any "normal" app]

> I'll switch back when Android can handle a screen rotation without blanking the screen.

hm, I don't have this experience, maybe last time you checked in an old android device or something ?

I've seen it on older apps and ones I've tried to make myself. The app where it's caused me the most grief is in AndFTP where rotating the screen will kill any in-progress file transfers. I've learned to just lock the screen rotation when I'm using that one, which definitely shouldn't be necessary but also isn't the end of the world.

> The app where it's caused me the most grief is in AndFTP where rotating the screen will kill any in-progress file transfers.

Imagine if every time you resized a window on your PC, the window got killed and restarted, and you see why bugs like that arise.

It'd be one thing if it was when the app is backgrounded, but no, even if you have one app running on your entire device, the UI be torn down.

It's insanity that in 2022 a major operating system is still doing that, and yet here we are with no end in sight.

There's a lot of insane things about modern operating systems. For example, some OSes don't even let you buy software without first paying the hardware manufacturer. Crazy stuff, we should really encourage regulators to bring these companies to their knees.

It's certainly crazy if you don't know better. The 48 billion in revenue the Play Store hit last year would tell you that regardless of security policy, people tend to use first party app stores on mobile.

But you know what? Maybe instead we should discourage people from clumsily trying to push their pet agenda the moment their favorite sports team (erm excuse me, Operating System) is painted in a poor light.

But we can't all get what we want can we?

That's actually part of the (intentional?) design of the Android framework underneath. By default, if rotation is allowed, Activities (basically a "UI screen", but not exactly) are destroyed and recreated when the screen is rotated. If the data structures AndFTP uses to manage/track the download are stored in the Activity, then they'll be destroyed on screen rotation as well.

This is something you learn very quickly once you start building Android applications -- or, at least, I did when I started back in 2011 (I haven't done much Android dev in the past decade since then). While I do think this behavior is a pretty terrible default behavior for the underlying UI framework, it's pretty bad that the AndFTP developers have not fixed this bug in their application -- and yes, it is a bug in their application.

The UI development paradigm has changed quite a bit over the life of Android, making "Fragments" more popular to use in some quarters than "Activities" as the "unit of UI screen" (though Fragments are still underpinned by Activities), but I believe the fundamental issue is still there: if you don't explicitly handle rotation properly, and store state in your Activity, it will get destroyed whenever the screen is rotated.

And THAT is an absolutely moronic design choice. Among many, but that one stands out.

Your device does it. These days it's hidden with clever animations so you don't literally see a blank screen, but the UI is being completely killed on each rotation.

Android will kill the user-facing portion of the process ("Activity") and recreate it* if you rotate the screen.

Devices have gotten fast enough to hide it with an animation, but it's still "kill UI, draw new UI". (specifically it's usually "render the UI to an image, squish it and rotate it, then show the new UI underneath".

My problem isn't with the literal animation, it's what that mess of rebuilding the entire user facing UI because they rotated their screen represents.

(* apps can opt out of this, but that's reserved for games and apps that render their own custom UI directly to a raw surface)

Ok is there a way I can “see” this, eg. Via adb ? Or via enabling some debug options ?

Not really? I mean maybe dumpsys window might give you a hint if the memory address of an activity changes, but it's not really an intended usage and I'm not sure it's fine-grained enough for that

But this is like ground-truth stuff about Android, about as immutable as it gets: https://developer.android.com/guide/topics/resources/runtime...

The best time to fix it was before the G1 launched and the 2nd best would have been right after, but here we are more than a decade later paying for its sins.

12 years ago people were asking for this stuff: https://www.reddit.com/r/Android/comments/djp18/i_know_its_s...