This is why Play slowly enforces apps to raise their compilation target and implement safer APIs. It's lagging for YEARS after API changes, so there's plenty of time to fix apps.
The OP just decided to be lazy and wait for last two weeks.
There has been zero communication towards me from Google until two weeks until deadline. Yes, maybe if I would have logged into Play Console then there might have been some notifications, but there have been no reason to do so until that e-mail (I'm usually not involved with Android projects, otherwise I might have noticed similar warnings via other projects early on).
But nice of you to assume he's lying. /s
But it's true that the first notice was sent months before the time limit, so he might have missed previous warnings.
Maybe it's possible that different roles in "Google Play Console" will receive different type of messages at different time? I'm not an admin for that app and it's possible that someone else has gotten prior warnings, but might have ignored these, because usually they are not with technical background.
Though unfortunately from time to time they also do break power user use cases…
The majority of applications deployed to android are targeting android's bytecode. They aren't natively compiled applications.
The reason C++ presents insurmountable security problems is it's low level nature and the fact that once you have a native binary, you're done.
But a bytecode for a language with memory safety? How would it be possible to not backport security fixes. The very nature of running such code is one where you are constantly recompiling the bytecode.
Just to paint how absurd this position is for google. The JVM can still, today, execute and use classes targeting Java 1.0 (released in 1996).
This isn't a security issue, this is a "google doesn't want to support the platform" issue.
I'm more amenable to google clamping down on artifacts containing natively compiled code. However, a blanked "Your app was built targeting an old version of android, we won't support that anymore" is just ridiculous. Seems like a way for google to prune old apps from the store more than anything else.
Especially since a policy like this is by it's nature one that shifts a large maintenance burden on android developers. After all, if you want the widest support for your application, you target the oldest version of android possible. Very few people target the latest version of android for fear it will lock out too many of their customers.
If google was serious about security and making the latest android tech widely accessible, then they'd work towards decoupling the android runtime from the operating system version. There's no reason ART and the Dalvik runtime couldn't be distributed via google play like the rest of the android ecosystem. Removing the silly "you need android 17 to do this... opps your hardware manufacture isn't updating their hardware drivers."
But then, that would cut into new device sales and we can't have that.
Only if you are lucky they don't depend on stuff that started being removed after Java 8, when deprecated for removal went into effect.
Plenty of libraries from that era didn't require unsafe code to accomplish their tasks.
I'm more than happy if google decides to break people who used non-public android apis.
Just browse the JEPs and release notes.
This is already the case.
Well, it is a platform security issue - sometimes a privacy issue.
Google essentially is improving security over time by fixing broken APIs which are deprecated and removed over time.
There are plenty of security and privacy related changes where APIs have been fixed in backwards incompatible ways. Essentially, this has been solved by adding more permissions - where either Google Play, or the user needs to consent.
In order to not break backwards compatibility this has been enforced based on the "target API level", and in order to prevent malware from simply targeting old API levels, they enforce this in Google Play by forcing apps to target current API levels.
In most cases, the changes required are rather small, sometimes code changes, sometimes compliance/documentation changes - or a combination.
MS expends an inordinate amount of effort on back compatibility, and much kudos to them. But it vastly increases their attack surface.
Likewise many of the worst things about the unfairly maligned C++ come from a hardcore position on back compatibility: as much as possible, old code, and even old C code, should continue to compile and work as expected, even to the point of linking old binaries to which you’ve lost the source code.
Most people don’t go to that effort and just invalidate old stuff in the name of maintenance, reliability, and security.
Whichever branch cut you take you’re going to cause a problem for somebody. If not, nobody is using your code.