3 ms·

>Google sent me a mail that "All new apps and app updates are required to provide 64-bit versions of any 32-bit native code they provide". So I won't be able to

>Google sent me a mail that "All new apps and app updates are required to provide 64-bit versions of any 32-bit native code they provide". So I won't be able to update existing app to existing users ever again, for non-technical reasons. Isn't the reason entirely technical? 64-bit apps can use 64-bit only instruction sets, which are newer and usually faster, resulting in a performance improvement. BTW, apple did the same thing years ago on iOS and is planning to kill 32-bit apps on MacOS soon.

izacus 7y ago
I think Google wants to allow OEMs to build devices that only support arm64-v8a arch - this will make the OS image significantly smaller because now they need to ship several components in duplicate - 32 and 64-bit versions. This is beneficial to total size of OS on the flash. Apple did this years ago.
- kalleboo 7y ago
  RAM usage as well as you no longer need to keep both 32-bit and 64-bit versions of OS libraries in memory at the same time.
jmiskovic 7y ago
Android was written for 32 bit. It couldn't run 64-bit before Lollipop. Currently there's about 2% of 64-bit Android devices (https://web.archive.org/web/20170808222202/http://hwstats.unity3d.com/mobile/cpu-android.html https://web.archive.org/web/20170808222202/http://hwstats.un...). I agree with performance argument, especially on battery-powered devices. But in this case there's nothing to be gained because LuaJIT is written for 32-bit CPU. Compiling for 64 bits won't do anything. Besides, hardly anything can squeeze more performance out of CPU than LuaJIT. I'm complaining different issue, though. I researched the platform requirements before investing time into android development. I shared my work for free because Google doesn't allow developers in my country to charge money for their work. I kept updating the app following the user feedback. I will lose the product because of this. This feels like rug being swept under my feet :(
- kalleboo 7y ago
  Why are you using an internet archive link from 2 years ago to support a claim about "currently"? It also seems to be misclassifying everything ARM into one bucket (probably because the stats were being collected from 32-bit code...). It looks to me like for the past 3 years every single mobile ARM CPU released has been 64-bit, and even for 2 years before that roughly half of them, the market share of these must be much larger https://dev1.notebook-check.com/index.php?id=149513&sort=&type=daysold&deskornote=3&or=1&showBars=1&geekbench2=1&geekbench3_single=1&geekbench3_multi=1&geekbench4_1_single=1&geekbench4_1_multi=1&passmark_cpu=1&sunspider=1&cpu_fullname=1&codename=1&mhz=1&turbo_mhz=1&cores=1&threads=1&architecture=1&64bit=1&daysold=1 https://dev1.notebook-check.com/index.php?id=149513&sort=&ty...
  - jmiskovic 7y ago
    This is the best data I could dig up. I would love to see newer statistics of market share, if anyone has a link.

izacus 7y ago

I think Google wants to allow OEMs to build devices that only support arm64-v8a arch - this will make the OS image significantly smaller because now they need to ship several components in duplicate - 32 and 64-bit versions. This is beneficial to total size of OS on the flash. Apple did this years ago.

kalleboo 7y ago
RAM usage as well as you no longer need to keep both 32-bit and 64-bit versions of OS libraries in memory at the same time.

jmiskovic 7y ago

Android was written for 32 bit. It couldn't run 64-bit before Lollipop. Currently there's about 2% of 64-bit Android devices (https://web.archive.org/web/20170808222202/http://hwstats.unity3d.com/mobile/cpu-android.html https://web.archive.org/web/20170808222202/http://hwstats.un...). I agree with performance argument, especially on battery-powered devices. But in this case there's nothing to be gained because LuaJIT is written for 32-bit CPU. Compiling for 64 bits won't do anything. Besides, hardly anything can squeeze more performance out of CPU than LuaJIT. I'm complaining different issue, though. I researched the platform requirements before investing time into android development. I shared my work for free because Google doesn't allow developers in my country to charge money for their work. I kept updating the app following the user feedback. I will lose the product because of this. This feels like rug being swept under my feet :(

kalleboo 7y ago
Why are you using an internet archive link from 2 years ago to support a claim about "currently"? It also seems to be misclassifying everything ARM into one bucket (probably because the stats were being collected from 32-bit code...). It looks to me like for the past 3 years every single mobile ARM CPU released has been 64-bit, and even for 2 years before that roughly half of them, the market share of these must be much larger https://dev1.notebook-check.com/index.php?id=149513&sort=&type=daysold&deskornote=3&or=1&showBars=1&geekbench2=1&geekbench3_single=1&geekbench3_multi=1&geekbench4_1_single=1&geekbench4_1_multi=1&passmark_cpu=1&sunspider=1&cpu_fullname=1&codename=1&mhz=1&turbo_mhz=1&cores=1&threads=1&architecture=1&64bit=1&daysold=1 https://dev1.notebook-check.com/index.php?id=149513&sort=&ty...
- jmiskovic 7y ago
  This is the best data I could dig up. I would love to see newer statistics of market share, if anyone has a link.