64bit testing hardware/emulation

[Yaron 53]

Now that 64bit is just around the corner, I recently found out that I'm lacking the 64bit hardware to test it (even on hardware with 64bit processor, it was running 32bit android).

What's more frustrating is that it's hard to even know in advance if a device supports 64bit.

Sure, it may have a 64bit processor, but is that processor running a 64bit version of Android?  I couldn't find out for a few models I looked into.

 

I also tried the Nox emulator, but sadly, I can't get any Delphi APK to run on it (when emulating Android 7, the most recent version supported by Nox), the app just closes unexpectedly right after the splash screen on an empty app (new blank project -> compile).

 

Any cheap & recommended device for testing 64bit?  Any other 64bit android emulation framework that works reliably?

Edited November 3, 2019 by Yaron

[Cristian Peța 103]

There can't be a device with more than 4GB memory and 32 bit OS.

You can take the cheapest with 6GB.

[Dave Nottage 557]

Yaron didn't mention a requirement of > 4GB memory; he was talking about devices with 64-bit processors.

 

Most devices manufactured since late 2014 are 64-bit, so choose one that was made since then, but always check by Googling the device info. It would be very unusual for a 64-bit device with Android 5 or greater to have a 32-bit version of Android.

 

[Cristian Peța 103]

I don't think so. 64 bit OS will use more memory than a 32 bit. With 2GB RAM it's better to run in 32 bit mode.

I have a Samsung A10 (model SM-A105FN released 2019) with 2GB RAM and running in 32 bit mode.

 

PS. It's running Android 9

Edited November 4, 2019 by Cristian Peța

[Yaron 53]

59 minutes ago, Dave Nottage said:

Yaron didn't mention a requirement of > 4GB memory; he was talking about devices with 64-bit processors.

 

Most devices manufactured since late 2014 are 64-bit, so choose one that was made since then, but always check by Googling the device info. It would be very unusual for a 64-bit device with Android 5 or greater to have a 32-bit version of Android.

 

Last year, I bought a cheap Chinese (CARBAYTA S119) tablet, 6GB RAM, Android 9 to verify that my apps work on the latest Android version and to play with tablet layouts.

It has a 64bit octa-core chip, but still runs Android 32bit.

 

Also, My Galaxy Note 4 runs Android 6.0.1 32bit, so the version of Android doesn't seem to matter either.

Edited November 4, 2019 by Yaron

[Dave Nottage 557]

27 minutes ago, Cristian Peța said:

I don't think so

You don't think what?

 

29 minutes ago, Cristian Peța said:

64 bit OS will use more memory than a 32 bit. With 2GB RAM it's better to run in 32 bit mode

Neither of us made any claim otherwise.

[Cristian Peța 103]

4 minutes ago, Dave Nottage said:

34 minutes ago, Cristian Peța said:

I don't think so

You don't think what?

I don't think that new devices with 4GB and less are running in 64 bit mode. Only some exceptions. The vast majority are running in 32 bit mode.

[Cristian Peța 103]

25 minutes ago, Yaron said:

6GB RAM, Android 9 to verify that my apps work on the latest Android version and to play with tablet layouts.

It has a 64bit octa-core chip, but still runs Android 32bit.

Running in 32 bit mode and accessing more than 4GB....

I thought this is a relic of an ancient era.

[Yaron 53]

Just now, Cristian Peța said:

Running in 32 bit mode and accessing more than 4GB....

I thought this is a relic of an ancient era.

I wouldn't be surprised if the tablet has 6GB but only 4GB is addressable.

Chinese tablets can be funny that way, like them marketing the resolution as 1900x1200, while in reality it's 1280x800 but with a scale factor that makes it appear to be 1900x1200.

[Dave Nottage 557]

33 minutes ago, Cristian Peța said:

I don't think that new devices with 4GB and less are running in 64 bit mode

I have a Pixel 3a running in 64-bit mode with 4GB of RAM.

[Yaron 53]

So far I tried the following emulators:

1. Nox 6 (Android 7.1.x)

2. BlueStacks 4 (Android 7.1.x)

3. VirtualBox with Android v8.1 64bit image (https://www.osboxes.org/android-x86/)

 

For some strange reason, none of them will even run the 32bit versions of a blank Delphi cross-platform app.

This is on a clean install of Delphi with a clean install of a fully patched Win10 running in a VM.

 

I guess my only course of action right now would be to buy a somewhat high-end device to be able to test 64bit development, but I would welcome any suggestions of a cheaper course.

[Marco Cantu 78]

We see a lot of recent Android devices with 64-bit CPUs but 32-bit OS. Odd, I know, I wasn't aware is this was so widespread.

 

As for emulators, the issue is they are mostly Intel-based, so Java apps run fine, but native ones require a ARM emulator like libHoudini (this was an Intel library, but I think they stopped all development since they exit the Android world)

[Rollo62 536]

1 hour ago, Marco Cantu said:

We see a lot of recent Android devices with 64-bit CPUs but 32-bit OS. Odd, I know, I wasn't aware is this was so widespread.

Would that mean that when NOT using the new AppBundle feature, and
the new Apps will be 64-Bit in coming Rx10.3.x,

then these 64-Bit APK won't run on those devices ?

Or will the coming Rx10.3.x version APK contain both, 32- and 64-Bit code ?

 

That would mean "AppBundle" is a must to support all devices with such 32-on-64 Bit OS, is that correct ?

[Yaron 53]

Regardless of the upcoming version, you must include both 32bit and 64bit APK files otherwise your app will not work on some devices.

 

I'm not sure if the play store allows you to upload separate APK files or you must upload an AppBundle.

Edited November 6, 2019 by Yaron

[Dalija Prasnikar 1396]

8 minutes ago, Yaron said:

Regardless of the upcoming version, you must include both 32bit and 64bit APK files otherwise your app will not work on some devices.

 

I'm not sure if the play store allows you to upload separate APK files or you must upload an AppBundle.

Play Store allows uploading separate APKs, but using AppBundle is easier.

[Rollo62 536]

@Dalija Prasnikar

Great, thanks for clarification. Never seen such feature to have separate APK, but good to know.

However, the AppBundle should be the way to go.

[Yaron 53]

On 11/6/2019 at 1:24 PM, Marco Cantu said:

We see a lot of recent Android devices with 64-bit CPUs but 32-bit OS. Odd, I know, I wasn't aware is this was so widespread.

 

As for emulators, the issue is they are mostly Intel-based, so Java apps run fine, but native ones require a ARM emulator like libHoudini (this was an Intel library, but I think they stopped all development since they exit the Android world)

Then using Android Tools, how should we configure an emulator?

I assume none of the x86 images would work (e.g. "Google APIs Intel x86 Atom_64 System Image").

This leaves the latest ARM system image, which only supports Android 7.1.1.

[Rollo62 536]

On 11/6/2019 at 2:18 PM, Dalija Prasnikar said:

Play Store allows uploading separate APKs, but using AppBundle is easier.

I just tried that out, with same app, compiled to 32-Bit and 64-Bit.
1. I uploaded 64-Bit version to internal test: All OK
2. I uploaded 32-Bit version to internal test: Failure: "You have already uploade app with same version code"

 

This is what I expected, so if you says its possible to upload separate 64- and 32-Bit apps, can please explain how ?
Of coarse I could upload 32-Bit with new version code, but isn't this new version then overriding the 64-version as well ?

[Yaron 53]

5 minutes ago, Rollo62 said:

I just tried that out, with same app, compiled to 32-Bit and 64-Bit.
1. I uploaded 64-Bit version to internal test: All OK
2. I uploaded 32-Bit version to internal test: Failure: "You have already uploade app with same version code"

 

This is what I expected, so if you says its possible to upload separate 64- and 32-Bit apps, can please explain how ?
Of coarse I could upload 32-Bit with new version code, but isn't this new version then overriding the 64-version as well ?

I doubt it will override the 64bit version, they request the version be the same to prevent people from releasing mismatched versions by accident.

 

[Dalija Prasnikar 1396]

14 minutes ago, Rollo62 said:

I just tried that out, with same app, compiled to 32-Bit and 64-Bit.
1. I uploaded 64-Bit version to internal test: All OK
2. I uploaded 32-Bit version to internal test: Failure: "You have already uploade app with same version code"

 

This is what I expected, so if you says its possible to upload separate 64- and 32-Bit apps, can please explain how ?
Of coarse I could upload 32-Bit with new version code, but isn't this new version then overriding the 64-version as well ?

I don't know what is exact process, as I never had to do it.  

 

Official documentation https://developer.android.com/google/play/publishing/multiple-apks

[Rollo62 536]

12 minutes ago, Yaron said:

I doubt it will override the 64bit version, they request the version be the same to prevent people from releasing mismatched versions by accident.

 

But I cannot proceed using the same version code.

 

3 minutes ago, Dalija Prasnikar said:

Official documentation https://developer.android.com/google/play/publishing/multiple-apks

Yes, I have to study this more deeply, but I'M not sure if that is related to the same apk.
Already the first view showas all these rules, I try to confirm as far as I can get today in red color:

Quote

Rules for multiple APKs

Before you publish multiple APKs for your application, you need to understand the following rules:

• All APKs you publish for the same application must have the same package name and be signed with the same certificate key.: OK
• Each APK must have a different version code, specified by the android:versionCode attribute.: OK, this can be done, I will try.
• Each APK must not exactly match the configuration support of another APK. Not sure what that means, TL;DR

  That is, each APK must declare slightly different support for at least one of the supported Google Play filters (listed above).

  Usually, you will differentiate your APKs based on a specific characteristic (such as the supported texture compression formats), and thus, each APK will declare support for different devices. However, it's OK to publish multiple APKs that overlap their support slightly. When two APKs do overlap (they support some of the same device configurations), a device that falls within that overlap range will receive the APK with a higher version code (defined by android:versionCode).

• You cannot activate a new APK that has a version code lower than that of the APK it's replacing. For example, say you have an active APK for screen sizes small - normal with version code 0400, then try to replace it with an APK for the same screen sizes with version code 0300. This raises an error, because it means users of the previous APK will not be able to update the application.
• An APK that requires a higher API level must have a higher version code. OK

  This is true only when either: the APKs differ based only on the supported API levels (no other supported filters distinguish the APKs from each other) or when the APKs do use another supported filter, but there is an overlap between the APKs within that filter.

  This is important because a user's device receives an application update from Google Play only if the version code for the APK on Google Play is higher than the version code of the APK currently on the device. This ensures that if a device receives a system update that then qualifies it to install the APK for higher API levels, the device receives an application update because the version code increases.

  Note: The size of the version code increase is irrelevant; it simply needs to be larger in the version that supports higher API levels.

  Here are some examples:

  • If an APK you've uploaded for API levels 16 and above (Android 4.1.x+) has a version code of 0400, then an APK for API levels 21 and above (Android 5.0+) must be 0401 or greater. In this case, the API level is the only supported filter used, so the version codes must increase in correlation with the API level support for each APK, so that users get an update when they receive a system update.
  • If you have one APK that's for API level 16 (and above) and small - large screens, and another APK for API level 21 (and above) and large - xlarge screens, then the version codes must increase in correlation with the API levels. In this case, the API level filter is used to distinguish each APK, but so is the screen size. Because the screen sizes overlap (both APKs support large screens), the version codes must still be in order. This ensures that a large screen device that receives a system update to API level 21 will receive an update for the second APK.
  • If you have one APK that's for API level 16 (and above) and small - normal screens, and another APK for API level 21 (and above) and large - xlarge screens, then the version codes do not need to increase in correlation with the API levels. Because there is no overlap within the screen size filter, there are no devices that could potentially move between these two APKs, so there's no need for the version codes to increase from the lower API level to the higher API level.
  • If you have one APK that's for API level 16 (and above) and ARMv7 CPUs, and another APK for API level 21 (and above) and ARMv5TE CPUs, then the version codes must increase in correlation with the API levels. In this case, the API level filter is used to distinguish each APK, but so is the CPU architecture. Because an APK with ARMv5TE libraries is compatible with devices that have an ARMv7 CPU, the APKs overlap on this characteristic. As such, the version code for the APK that supports API level 21 and above must be higher. This ensures that a device with an ARMv7 CPU that receives a system update to API level 21 will receive an update for the second APK that's designed for API level 21. However, because this kind of update results in the ARMv7 device using an APK that's not fully optimized for that device's CPU, you should provide an APK for both the ARMv5TE and the ARMv7 architecture at each API level in order to optimize the app performance on each CPU. Note: This applies only when comparing APKs with the ARMv5TE and ARMv7 libraries, and not when comparing other native libraries.

Failure to abide by the above rules results in an error on the Google Play Console when you activate your APKs—you will be unable to publish your application until you resolve the error.

There are other conflicts that might occur when you activate your APKs, but which will result in warnings rather than errors. Warnings can be caused by the following:

• When you modify an APK to "shrink" the support for a device's characteristics and no other APKs support the devices that then fall outside the supported range. For example, if an APK currently supports small and normal size screens and you change it to support only small screens, then you have shrunk the pool of supported devices and some devices will no longer see your application on Google Play. You can resolve this by adding another APK that supports normal size screens so that all previously-supported devices are still supported.
• When there are "overlaps" between two or more APKs. For example, if an APK supports screen sizes small, normal, and large, while another APK supports sizes large and xlarge, there is an overlap, because both APKs support large screens. If you do not resolve this, then devices that qualify for both APKs (large screen devices in the example) will receive whichever APK has the highest version code.

  Note: If you're creating separate APKs for different CPU architectures, be aware that an APK for ARMv5TE will overlap with an APK for ARMv7. That is, an APK designed for ARMv5TE is compatible with an ARMv7 device, but the reverse is not true (an APK with only the ARMv7 libraries is not compatible with an ARMv5TE device).

When such conflicts occur, you will see a warning message, but you can still publish your application.

 

[Dalija Prasnikar 1396]

4 hours ago, Rollo62 said:

But I cannot proceed using the same version code.

 

Yes, I have to study this more deeply, but I'M not sure if that is related to the same apk.
 

It is related to same apk.

 

I know for sure you can upload multiple apks because I know some developers have successfully used that feature. So I know this is possible, I just don't know the details and I cannot dig up particular conversations. 

 

But, App Bundle is the way to go so you don't have to worry about multiple apks.

[Doug Rudd 2]

I bought a used Samsung Galaxy S6 on eBay. That and any newer S model is 64 bit.