More like google's fault. They made a huge mess of completely different permission and behaviour changes between 11, 12, 13. At least since 14 they have stopped fucking around so much.
It is really much simpler for us to cut off all versions before 12, but it's unfeasible. So many devices still with 10/11. Now we cut off at 8.1, but will increase that every year starting next year as google mandates us an increase of minimum sdk version.
I don't like how companies behave like that and basically push users to upgrade their phones
Garmin in particular makes it mandatory to use their app for SOME connected functionalities (while others work just fine on wifi or wifi tethering).
They unsupported old version of android for the garmin connect app pretty fast (my mom's phone was incompatible within 4 years of its release) while they don't support you to connect older devices on newer phones and say they know it doesn't work.
As a user, I don't care whose fault it is.
I ditched both Google in favour of degooglized android on older Xiaomi and Pixel phones that support custom ROMs, and Garmin for any sport equipment.
My next phone will be a Fairphone if they make something with a smaller screen.
I don't know which app you're doing, but I would most likely permanently just not download it or find an open source alternative if it stopped working for me, as no app is essential.
Pay attention to the user-base, in particular is your app is supposed to work with a web of users.
While i always try to look for open source utility apps (i use several), our userbase simply don't care.
Context: Our apps are means to connect to our devices via BLE, are free and without ads (fuck ads, fuck all ads), no integrity checks. We don't publish the API but we know of a couple of clients that reverse engineered the protocol and made their own. Good for them. (one of them also came by the office to bring a friend and showed us his app that glued together the functionality of several modules from also our competitors. Cool!)
But given what we do our customers are complete normies, doing what google asks us is the path of least resistance, and gets us most audience.
Those who don't want to use the play store can find the APK in the usual sites, don't care.
If i made app for myself i would indeed distribute it differently.
I haven't done Android dev in a while, but I remember the Android SDK offered a 'backwards compatibility pack' - you selected which version you wanted to target, and how old a version you wanted to support (you could go back to like android 5) and it gave you all the polyfills necessary. The only downside was that your app size would balloon to crazy levels.
It's more or less what minimumsdk does, but there may be libraries that require you to bump the minimum.
For example, there are APIs that make feasible something that should be trivial (like autosizing a font based on size, the way it happens in iOS) but they are available from 8.0 so you cut out anything below that.
Or, we use BLE a lot and there are newer methods that makes our life easier but again are not available in older SDK versions
>Forty 9003s were installed, offered via lease between 1959 and 1964. The first 9003 was installed at Marzotto in Valdagno
I pass by marzotto almost every weekend during winter (GREAT spots for goulottes). I didn't know that one of the first computers in italy would be installed there.
Such a shame, the rise and fall of marzotto and recoaro.
It's incredible how small apps get when you throw away all the bullshit: useless frameworks, ads, third party libraries that require you to include a huge binary.
People are always amazed when i show them my apps are 2-5 megs, and that's because there's 2-5 megs of assets.
Exactly! That’s exactly the philosophy behind MBCompass keeping the core functionality focused and lightweight, without unnecessary frameworks or bloat.
People are often surprised by how much you can do in under 2 MB.
There are also frameworks that don't bring in anything unless required. I use B4X for most of my apps.
It has a fundamental issue, which is being single threaded (with exceptions), but it's truly lightweight and easy to extend, and the team behind it really know their business.
Disagree. The main reason we use chinese fabs is because we can actually get the goods in less than three weeks, so if we have a surge in sales we are covered pretty quickly.
The other reason is that we do some low complexity boards all specified with chinese parts, JLCPCB for the win, and our contractor agrees with us. They are not interested in those jobs because they can't possibly compete.
However, for our batch size/complexity our local contractor beats the chinese, by a good margin, and they keep growing the business. In Italy. The only problem we have with them is lead time, because there is always some hiccup, some missing part, some email that gets answered a day too late. I've been asking them for years to just provide their catalog with their partnumbers so i can just specify them in the BOM, and we won't waste all that time back and forth, but it's never been a true priority, but they do need to streamline the process. All european manufacturers need to streamline their process.
Another comment here lamented that the issue is that the fabs may try to treat every board as unique, whereas is should be us designers that adapt to them. I agree. That's a general issue in our attitude to designing a product, in many areas.
Manufacturers in china just do it fast, and avoid all the pains, they actually care about customer experience above all, something we have to learn from ourselves obviously!
As I said in another comment, I fully expect things to change for the better: Some manufacturers will go out of business, but yet others will turn around in time.
All these people that were laid off will find jobs again, revitalizing moribund companies. Some will create their own companies, I view myself as part of this group.
I don't know man, i have a bunch of computers, the oldest one is a 2012 macbook, then various laptops from different brands (hp, dell, lenovo), an intel nuc from 2016 and a minisforum using a ryzen 7 that i bought just before the ram craze (phew)
all these machines run debian trixie with KDE and i think i only ever seen glitches once, or twice in only one of them. I think the macbook. Granted, all devices run from the internal GPU, intel or AMD.
The only time i saw kde "krash" a lot was when i was demoing arch in a VM, to see what the fuss is all about that distro. But i don't know if it was virtualbox, or arch.
Which is what we're doing. The moment your app isn't some webview react crap and start using any non basic (or even basic) features you end up with two codebases. For example, anything using foreground services or requiring runtime permissions.
The only framework i found that really bridges the gap is B4X, but you still need to have two separate projects, because of services, and #if blocks for the things the framework doesn't abstract (which, to be frank, is really just advanced uses of peripherals and libraries)
let me know when my embedded target's compiler is C23 compliant (i mean, i whish. we may be getting C11 or even C17 some times next year but i'm not holding my breath)
What are you targetting? for instance all ESP32 now support GCC15 which has support for #embed. AVR also has GCC 15 toolchains for months, as well as ARM which also allows you to target STM32 and Nordic nRF stuff.
More like google's fault. They made a huge mess of completely different permission and behaviour changes between 11, 12, 13. At least since 14 they have stopped fucking around so much.
It is really much simpler for us to cut off all versions before 12, but it's unfeasible. So many devices still with 10/11. Now we cut off at 8.1, but will increase that every year starting next year as google mandates us an increase of minimum sdk version.
reply