u/derefnull

This is exif data

It also contributed things back to the Linux kernel that lived in the Android fork for a long time. Binder and wake sources jump to mind as the two major examples, but I'm sure there a lot of other features that have been merged back over the years.

And many of it's engineers went on to make Android, including people like Dianne Hackborn and Hiroshi Lockheimer.

None of the apps you're taking about would be impacted anyways; they'd be required to register regardless in order to be available (unless these apps are not typically available in any Play-centric region).

What did they do to Virtual Displays?

Except revenue is up for a lot of companies doing layoffs. Take Alphabet for example: Revenue is up 13% YoY for Q4 and 10% YoY for 2023 as a whole. Net income is similarly up YoY ($23.7 billion in Q4 2023 vs $18.1 billion in Q4 2022). Other major tech companies are similarly doing well.

And yet they're still laying people off, so falling revenue is clearly not the root cause in these cases.

Anyone know what he's referring to when he says the haptic patterns are worse in Android 13?

If I move to a more expensive area, they aren't going to increase my wages.

Actually, they do, at least when moving office to office. Whenever you transfer sites, pay packages are re-evaluated based on the target salary of the office you're moving to. I've seen a number of people move sites because the pay is better elsewhere.

Is "screen fixing" the same thing as "app pinning"? Maybe Xiaomi just had a different name for it. If so, try searching settings for "app pinning" and see if anything comes up under that name. If that doesn't work, you can try connecting your device via adb and running adb shell settings put system lock_to_app_enabled 0.

They didn't though. Last line of the Google code of conduct:

And remember… don’t be evil, and if you see something that you think isn’t right – speak up!

An API was added in Q to record app audio. See AudioPlaybackCaptureConfiguration.

Note that this is just for things developed internally, like the design support library. I don't believe there are any plans to change the standard for AOSP, or AOSP developed code at this point.

Until you open the application for the first time, it can't run anything in the background. The whole application is considered to be in the "stopped" state.

Until you open the application for the first time, it can't run anything in the background. The whole application is considered to be in the "stopped" state.

It's still in the corporate code of conduct, which is the same place it's always been:

And remember… don’t be evil, and if you see something that you think isn’t right – speak up!

This was fixed in O, it's now updateable out of band with system updates.

Yes.

A few of them now work at Google on the Android platform itself (e.g. Jeff Sharkey).

You're talking about two sets of developers here though: the OEM platform developers and the application developers. Platform developers that do customizations on top of the are going to have to port their customizations to the new platform version when it gets released; whether 3rd party app developers have to care about those customizations is where the fragmentation question comes into play.

What I'm trying to say is: whether platform developers have to do per-device development is somewhat orthogonal to whether application developers have to deal with fragmentation.

The app store lets you filter which devices can install your app by a number of categories (docs), including by ABI.

While Andy Rubin founded both Danger and Android, Android was not started at Danger and is entirely separate in terms of technical foundation.

I think many of us take the shortcuts that Dianne mentions in this article. For example, you start a thread to update your database from an activity (instead of putting that in a service) without considering the corner case like preferences (and then find some users have weird bugs).

Services and threads are completely orthogonal; anything you do in a Service's lifecycle methods is happening on the main thread and competing for CPU time with your UI. Whether you use a Service or not, you must manage your own threading and handle impending process death either by blocking until completion when the system tells you you're going away soon (onStop/onDestroy) or handling the data loss gracefully (which you should do anyways because your process could die for lots of reasons).

But there is that nagging thought "what if I need to split this into multiple processes, or allow other apps to communicate with this app via bound Service / Content Provider?" ... then the shortcuts give way to their full versions; likely app needs to be redesigned.

I would strongly recommend that you don't design around these concerns until you have to. They can greatly complicate architectural decisions and 99.9% of the time, applications don't need to anything remotely like this.