11–20 of 30 posts
I guess Google play store can restrict the downloadable set of apps to what is natively compiled for available hardware. So why this over-the-top feature than?
Reminds me of libhoudini (ARM -> x86 translation layer) from the days when x86 Android phones were still thing. Performance wasn't amazing but compatibility was surprisingly good.
I guess Google play store can restrict the downloadable set of apps to what is natively compiled for available hardware. So why this over-the-top feature than?
I don't know if it's over the top. ARM isn't too complex to convert. There's some register mangling that needs to be managed for SIMD, data struct alignment checks and overbounding behavior that needs to be accounted for; but it's all relatively (keyword on relatively , it's still a lot of work) simple and orthogonal. I would assume it's provided because in Xiaomi's primary two markets (India and China), there's a to…
The paper https://dl.acm.org/doi/10.1145/3140587.3062371 is also related to the emulator that they are using.
I'm happy to answer any questions you may have about the technology.
I guess Google play store can restrict the downloadable set of apps to what is natively compiled for available hardware. So why this over-the-top feature than?
Because Xiaomi cares about software backwards compatibility on its devices? Just because many people are now used to being told "this app developer hasn't updated their app in a few years so now you can't use it, tough shit" doesn't mean it should be the standard.
I guess Google play store can restrict the downloadable set of apps to what is natively compiled for available hardware. So why this over-the-top feature than?
Not only that, since 2019 Google have required apps published on play store to have 64bit variants, this should not be a problem. However I suspect that the Xiaomi has to contend with the Chinese app ecosystem which may not be as strictly controlled, so probably has a decent number of legacy 32bit apps floating about.
Reminds me of libhoudini (ARM -> x86 translation layer) from the days when x86 Android phones were still thing. Performance wasn't amazing but compatibility was surprisingly good.
Hello HN! I'm the main developer behind the Tango binary translator. I'm happy to answer any questions you may have about the technology.
What was the main technical challenge of this project and what was the solution?
Hello HN! I'm the main developer behind the Tango binary translator. I'm happy to answer any questions you may have about the technology.
It seems to me like everyone from Qualcomm over Android to manufacturers would want this. Why did you have to build it instead of them? And is Xiaomi the entity licensing it from you? Does this mean that there will likely be implementations of the Snapdragon 8 Gen 3 that don't support 32 bit apps?
Is this just such a niche problem because most phones have been on 64-bit processors for so many years so that vendors expect the compatibility breakage won't be too big?
How did you anticipate this issue and how are you using the situation? i.e. do you already have experience/contacts in the industry?
Phew, that's a lot of questions and I get it if you don't want to answer all of them. Thanks for your time and stopping by!
Hello HN! I'm the main developer behind the Tango binary translator. I'm happy to answer any questions you may have about the technology.
Congrats! What was the main technical challenge of this project and what was the solution?
One challenge that particularly comes to mind was dealing with anti-emulating/anti-debugging code in various Android applications. These apps would do all sorts of crazy things like attaching to themselves with ptrace, installing bizarre seccomp filters which check for specific 32-bit syscalls and using self-modifying code without proper cache flushing to check for the presence of an instruction cache.
The solution for each of those was to emulate the relevant functionality well enough to trick these apps into thinking they were running natively. Although in the case of self-modifying there was no good solution and we ended up hard-coding some particular instruction sequences in the translator for special handling.
One thing that really made the above possible is that for Tango v2.0 we re-wrote a large part (~half) of the codebase in Rust, which was previously entirely written in C. In particular, the ptrace emulation code needs to maintain a lot of internal state about traced threads. This requires maintaining complex data structures, and the ability to easily use enums, Option, HashMap, etc, is a huge help for this.