FYI, Mishaal is also on Mastodon, and the posts are the same as on Xwixxer so it might be better to post those posts instead in the future https://androiddev.social/@MishaalRahman
Xwixxer
Haven’t seen that one before, in German it sounds like “Xwanker”
Running Flappy Bird just fine on Android 14 Samsung
That’s most likely because it does have 32-bit support on some cores. Thus, no emulation layer is required.
Android’s compatibility has been a mess for all of time really but I feel like it’s gotten to a new low recently. It’s kind of crazy how many games or apps that are only a few years old won’t work on newer versions of Android anymore.
Two main reasons:
-
Cutting off older API versions to enforce tighter security requirements
-
Dropping 32-bit hardware from newer phones breaks apps with 32-bit binary components such as libraries.
Dropping 32-bit hardware from newer phones breaks apps with 32-bit binary components such as libraries.
How badly did they have to fuck it up for it not to be backwards-compatible? Isn’t it trivial to just pad out the upper (or whatever, given endian-ness) half of the register with zeroes?
I’m so glad you asked because I specialize in instruction set architectures of all kinds in my day job. You can’t simply pad larger registers. The instructions themselves, the native binary code that the processor executes has changed. If you want to execute different native code, you need different hardware.
The relationship between 32-bit Intel and 64-bit Intel is a very generous one, providing lots of opportunity for backwards compatibility. You can’t buy a 64-bit only Intel processor for example. Here, when I write Intel I mean x86, not necessarily the manufacturer Intel. Even processors marketed as exclusively 64-bit must contain the 16 and 32-bit modes. Therefore, running 32-bit code on a 64-bit x86 family processor is a relatively simple task in principle. You enter the mode that you need, and the instructions have many similarities.
64-bit arm (actually aarch64 or Armv8) is remarkably different from 32-bit (armv7). Firstly, there is no expectation that 32-bit mode will be available. It saves space, power, and area not to include the support, and all of these factors are especially important in the mobile realm. Given that the binary instructions are so different, there’s very little to be gained by combining support for the two. They’re basically different languages.
Mostly Eastern handset manufacturers still include the 32-bit hardware because third party app stores in those countries frequently offer 32-bit binaries. Even then, it’s relegated only to the low or middle performance cores. Vendors targeting Western markets prefer to leave it out so they can invest more heavily on the 64-bit side and obtain better performance for most apps.
However, as the article shows, this is changing. We’re starting to see a shift to 64-bit only hardware and instead using creative software techniques to bridge the gap. The alternate solution is to translate the code into a form that the hardware does understand at run time, at a cost of some performance and memory.
-
Ios isn’t better either. Got a new iPhone for work recently, so I thought I would re download some of the games I used to play as a kid. Most of them have been removed from the store at some point so you can only access them if you have purchased them previously. From the older ones many haven’t been updated to support newer os versions. Some others you can’t even download anymore (even if you own them) because they have been removed from the store completely (e.g. Infinity blade). It’s sad seeing this entirely unaccessible. You’d basically have to have an old jailbroken iPhone to try to run most of it, and you would have to source the APKs somehow. It would be cool to have an emulator for these old games.
I wonder if handsets sold in China will include tango. Since the Xiaomi 14 also used tango for 32 bit support.
