I have a fairly specific question, and I couldn't find something that really addresses my scenario.
We have an app in the Play Store. It's been there for years with periodic updates. Most recent update would bomb out on upload, and the Play Store made me update to minSDK (edit for this typo, TARGET not MIN) 29. Did so, and upload proceeded fine, but rolling out is troublesome because that puts a lot of users outside the update path and future updates.
I have personal feelings about Android and what I consider to be an idiotic model of leaving the carriers and MFGs to handle updates resulting in exactly this situation as they are clearly preferential to selling newer phones to customers, but that's a whole other discussion.
I don't really know what to do next; the Play Store doesn't seem at all interested in letting me upload my AAB at anything less than API 29, and a big percentage of my users are on Android 8, with some on lower versions. They can install, but can not run; immediate startup crash, and I can't reproduce it.
Anyone more familiar with Android deployments have some ideas or thoughts that I'm (hopefully very clearly) missing? I can't mandate a bunch of people run out and get new phones, especially those on company-supplied devices, but I also can't believe there's no other recourse for me to get my users updated.
Everything I find in all the google stuff starts with: 1) Make sure you have the android 29 SDK:
(sigh)
Thoughts? Thanks!
Google Play does not require you to have a minSdkVersion of 29 but instead a targetSdkVersion of 29 as of December 2020.
You can change the minSdkVersion to the minimum android version you want to support but you must have a targetSdkVersion of 29 or higher.
Ultimately, the issue was an unlogged error that I couldn't reproduce in debug/dev/testing, and only appeared in Release level builds, per this:
https://github.com/flutter/flutter/issues/58479
I hate this platform.
Thanks, all.
Related
I do not work with code at all. But we have 1 app on android programmed with React Native (old version).
Some told me that when Android Q (or 10) is published we need to upgrade our source code to be able to "publish" new apps or new updates to the stores.
This is true? If this is true, before what date we need to update our code for posting new updates or versions?
Thank you very much!
No. As of August, the Google Play Store required your targetSDKVersion to be at least 26, and I'm sure in a year or so they'll up it to 27. But nothing is needed just to support Android Q, unless your app is using a feature/API that got significantly changed.
Google recently released a new version of Google APIs for Android and it struck me as pretty weird why they would jump 3 major versions up. As far as I can see they didn't explain it in the release notes, so my question stands as in the title.
Why did Google decide to jump from version 12.0.1 to 15.0.0 with Google APIs for Android?
This is possibly due to culture specific superstition, 13 being considered an unlucky number in western cultures, and (1)4 in eastern cultures.
Related:
Software versioning superstition (wikipedia)
Is v15 of Play Services a late April Fools joke? (reddit)
Play Services 15.0.0. Why the huge jump in version number? (reddit)
Special care may be taken to avoid occurrences or reminders of the number 4 during everyday life, especially during festive holidays, or when a family member is ill. Mentioning the number 4 around a sick relative is strongly avoided. Giving four of something is strongly discouraged. Elevators in Asia and Asian neighborhoods often skip the 4th floor or any floor whose number contains the digit "4" (as 14, 24, etc.). Military aircraft and ships also avoid the number 4 (such as the South Korean and Taiwanese navies) due to its extreme negative connotations of death. April 4 is also considered an exceptionally unlucky day (much like Friday the 13th in the West).
From Tetraphobia
In a Reddit thread about Google's recent announcement of a new SDK versioning system, someone claiming to be a Google employee offered the following interesting explanation.
Googler here: the big version skip is just an implementation detail. We have been working on this new build process for a long time in parallel with other Play services releases and we needed to pick a "base" version where the versioning logic would change. We had to bake this version into a number of things, for instance Android Studio knows not to raise the old "different versions" lint error on 15.0.0+.
As for the semantic versioning, we actually have not been following SemVer at all in the past. The SDK just bumped by 0.2.0 each planned release, and if we made mistakes we'd release +0.0.1 patch versions until it was fixed. So for instance 10.0.0 was not a breaking change from 9.8.0, in fact it was a kind of boring release.
In the old days the version number used to tell you what version of the Play services app it was compatible with and it would be some ugly thing like 7.8.49 but we stopped doing that around 9.0
They didn't jump actually. Play services are released every month. Version 11 has been released in December. So in April they released version 15. I guess there was some problem in the meanwhile so they release version 12 (the january version) in March, i.e. two months later, maybe 13 and 14 weren't yet ready for production. However the versioning is totally consistent.
This is called pre-planned before releasing the version.
Why Google have switch from 12 to 15 directly
They have kept the backup of 2 version for there updates reason behind that can be
People are not updated with the new version: If the old user are not updating there project with the new version and if something extra added to this version will be not present in old version for them, there will be update. So they can also get the same funtionality, as we can see there are around thousands of users who's app have the old version.
Example- For 12 version User there will be edited update with 13 version which will not effect any kind of there funtionality
People who are updated with the new version: If there will be major update in the 15 version and that may cause issues that require long time to recover so till that time the user, So the user cannot wait till that time for them there will backup so that they can get rollback to version 14 and continue till the problem will resolved,
Example- For 15 version User there will be issues and rollback then they will get update with 14 version which will not effect any kind of there funtionality, they continue there work.
if both scenario comes true then there will be both option available for them
Example- For 15 version User there will be issues and rollback then they will get update with 14 version which will not effect any kind of there funtionality, they continue there work.
Example- For 13 version User there will be issues and rollback then they will get update with 12 version which will not effect any kind of there funtionality, they continue there work.
Google doesn't use any major build number because of their continuous delivery.
I assume the versions 13 and 14 may have been delivered only in internal build and didn't make it to the public release.
I have an app in the market that is targeting Android SDK 23 at the moment.
My problem is that with the release of Android 6, users have to accept dangerous permissions at runtime. I have got my first crash regarding this and I want to solve it fast before it gets serious.
I want to do it correctly as Android recommend asking the user at runtime to accept the permission and if not, hide the feature and stuff. But that takes time and will be done in the future. :)
But, would be for now changing the targetSdkVersion to 22 be a valid solution? What would that mean for users with Android 6 that have already installed the app?
I hope my quiestion is clear, thanks a lot!
If an app targets the Marshmallow SDK, it means that the app is aware of the new features and can use them
I think that if you're not handling the permissions as Android 6 is supposed target it one API lower because this is the compatibility of you're app
Btw it is recommended to ask the critical permissions on the start of the app and the minor when needed.
Hope that I helped.
One of my existing launched app's minSdkVersion is 4, but now I want to provide an update , which minSdkVersion is changed to 5.
I have tried and upload to the market is okay, but what will happend when this update is really being rolled out?
What would happen to the user with device can't meet the requirement? Any side effect except they won't be able to install the app in the future?
Thanks.
If you "deactivate" old apk file in developer console - your app will we able for downloading only for API 5+. There will not be any effect for people with API 4 and already installed app.
If you keep both old and new apks in market in "active" state, then market will offer old one for people with API 4 and new one for people with API 5+. Also they will be offered to update your app.
When you add apk that supports less versions than old one, you will see this:
http://take.ms/E0SYg
Market resolve itself what apk to give user.
SoundPool has a serious bug in it in Android 1.5. I fixed it with a workaround, but since it really limits my app, I want to target 1.6+ for the next version of it.
I am wondering: What happens when I release a upgrade that has a higher target SDK version then the previous version of my app? Will only 1.6+ users be able to upgrade their app? Or will also the 1.5 users be able to upgrade since they have the program already installed?
Anybody experience with this?
Since you answered one of my questions, I thought I'd take a look at your questions:-
From what I've read on the Android dev site:-
The manifest holds the MINIMUM version that the APK will support. Only users with the same version or higher of that SDK will be able to even see you App in the Market.
Therefore, to answer your question, YES, only users with OS 1.6+ Android will be able to upgrade. I released an app once, set to 1.6, and wondered why I was getting less downloads, then realised what I had done, set it back to 1.5, and all was well.
Is there anyway you could get the newer 1.6 source for soundpool, add that to your app, and use it when version 1.5 is detected (or, just use it all the time).
Lots of hassle I know, but just a thought.
Havn't got any experience with this but that a 1.5 user can use an app targeted for minimum 1.6 seems highly unlikely. They will probably be informed that your app no longer supports their platform or just not recive the update.