Even so, google being forced this way will make app installation/updates much more convenient for non-root and oem-rom users. And ensure rhe aurora store or a future iteration of it aren’t going to flag peoples accounts for google to take action against them.

FWIW some of the problems are on website/app developers. Not sure on specifics on the app side, but with websites if the dev doesn’t use semantic html input elements with the correct type attribute to denote the password form, autofill won’t work (since neither android or the password manager know its time to do stuff)

Nothing wrong with username/password on different screens (one at a time is good for several accessibility-minded reasons) but again, there are some best practices to follow which allow screen readers and password managers to still act as you would expect.

I’d assume android app dev is similar.

That said… I do think it’s gotten a bit clunkier at times in ways I dont recall being problematic in the past. I use 1password and heliboard or floris board and while those keyboards seem to bug out a bit, sometimes the bigger problem seems to be that android isn’t always telling 1password enough info to find the right account. Idk how apps “inform” the password manager (maybe via url’s in a metadata file or maybe passwors managers have ro keep theor own internal db?), but apps that use web wrappers (specifically the old and/or shitty ones) report their url as http://localhost/ since the wrapper just renders a local page in a web view. that’ll wreck a password managers day real quick.

Idk if Android is worse than iOS here, not that it is a reason for google to punt on improving it. iOS has its own autofill quirks thay can be just as annoying. Esp constantly asking if you want to use your app or apple keychain without a way to just pick a default…

Might as well switch now to something which largely works better and is more feature rich.

Which is relative to personal taste and needs.

If I was going to trust obsidian, their code would be fully foss.

I definitely agree that I wish it was fully foss, but i also think it is a far better option than notion, onenote, etc for most people (as long as it meets their needs and preferences) since with obsidian you do actually own your data and you don’t need to pay unless you want their sync.

Since it isn’t, there is nothing future proofing my notes in their software.

Even if, worst case, Obsidian enshitifies, all the notes are markdown or json (json for config and things that don’t work in markdown, but the community and the devs work hard to keep that to a minimum) so you can still access your stuff in any text editor and it will be fairly easy to get the important data migrated into anything else. (I often use vs code to manage my notes, for instance, esp for big find and replace or re-org tasks) Even the non-standard markdown from obsidian and the most popular plugins reads well and could fairly easily be replicated with remarked or other markdown libraries. In this way, i think Obsidians approach is far superior to a tool which uses a database to store its data, since a database would require some effort to use standalone, or some work to migrate it to another tool or some sort of minimal client interface.

By its design, Obsidian could also be replaced by reverse engineering their api. If obsidian takes the dark path, we will probably see a foss community grow from the plugin dev community to replace it and be as compatible with plugins as possible, even if its just the basic text and display components. Tbh, it could totally be a vs code plugin, an emacs mode, [insert any text editor with plugins here]… thats how portable the data is. The obsidian devs know this, and they are intentional about staying this way. A shift in attitude here would be noticed by the community very quickly.