Currently, existing apps (across mobile, Android Auto, Android TV) must target API level 31 or above by August 31, 2023 (target API 30 or up API level 33 for Wear OS). Otherwise, they will stop being discoverable to all Google Play users whose devices run Android OS versions newer than your app’s target API level, as your app wasn’t built to meet the safety and quality standard that these users expect from newer Android OS versions.
Apps with a target level of Android 11 (API level 30)* or lower will not be available to new users running the Android OS higher than apps’ target API after August 31, 2023.
Apps with a target level of Android 10 (API level 29) or lower have not been available to new users running the Android OS higher than apps’ target API after November 1, 2022, or May 1, 2023, if your app had an extension.
Again, this has literally nothing to do with the play store. This is API 22 and below we are talking about here... you can't even find apps that target API levels below 30 on the play store today afaik lol.
Keep in mind this isn't the minimum supported version, it's the target/compile version which is typically pretty trivial to update. 99.9% of users in 2024 will never need to install an app that targets a version of Android released 10 years ago.
It's actually even better than that. Because this is an OS provided picker the app only gets access to the photos you select, instead of all of your photos.
You seem to be misinformed about what's actually happening here. If there is a super old app you need you can still install it via adb.
This has absolutely nothing to do with the play store and its requirements. This is about preventing malware (which is typically written to target super old API levels to exploit things that weren't patched yet) from being installed unknowingly by the user.
The design here is good. If you are tech savvy enough to use adb you can install anything you want. But this protects somebody that mistakenly thinks they are installing something safe from accidentally infecting their device.
Fair enough. The OS should handle these characters automatically based on the selected language and I would expect Android to; I just don't know for sure that it does.
My point was simply that these characters/symbols are Unicode so a keyboard running QMK or similar should be able to send them directly. However, you are correct that it shouldn't be necessary.
Swipe up to continue: Fold your phone and swipe up on the front display to continue using the app, or wait a few seconds for the screen to lock
That's an interesting option I might try, but I honestly think I'll set this to "never". I'm always happy when we have options on how to use our devices but for me personally closing the phone when I'm done using it is the most natural.
I don't believe has an option to encrypt notification content either.
This is not an option you would actually want from any service.
You don't want to be giving the plain text message to anyone to encrypt. Instead the notification contents should be given to the service provider (FCM or anyone else) already encrypted and only able to be decrypted by the app.
This is a weird hit piece where the author has all the facts but seems to just not understand them...
The TL;DR (that we knew months ago) is the 8GB of ram in Pixel 8 isn't enough to run the Gemini Nano LLM on device, the 12GB of ram in the 8 Pro is actually needed.
Again, strange to call this a "fail" when Google is the first and only company to really do this and never claimed it was coming to the 8. This is the bleeding edge, of course it only runs on highest spec hardware.
Host computer is an old i7 desktop running proxmox. I don't think that's the problem.
I just think a native dashboard in the apps would be better for a bunch of reasons and the Home Assistant project is big enough now to support/warrant it.
Are you are implying that somehow going native gets you faster network transmission speeds?
No. If the components are native they can be loaded immediately without network transmission. The network calls for the current status of entities can happen in parallel and would complete much faster than one large webpage load.
And your standard cards can not be modded with CSS unless you install something 3rd party that allows that.
Pixel Fold. It takes ~2 seconds on gigabit WiFi. Slow 4G networks take a lot longer than 2 seconds. Could be pretty much instant regardless if it was native.
I work in mobile and respectfully disagree with it having no impact on time to show. You might not notice much difference if you are inside your house using gigabit WiFi, but go load your dashboard on a slow 3G/4G network lol
Sure, there is a higher development cost but you get what you pay for in this case. The project already supports native apps for Android, iOS and Mac.
Drag n drop is great but honestly what I want is a native UI on each platform.
I realize that they aren't reinventing the wheel with the UI updates this year so it's not really comparable/fair to say but I just want something faster and more responsive (especially on mobile). It seems crazy to me that in 2024 the fastest hardware available still takes a couple seconds to show my dashboard on a cold boot of the app.
Again, you appear to be misinformed...
Source