Fix INSTALL_FAILED_OLDER_SDK & unknown target CPU 'intel'

[trholding]

When building with SDK 34 the following error occurs on devices that need older SDKs:

Failure [INSTALL_FAILED_OLDER_SDK: Requires newer sdk version #34 (current version is #33)]
Performing Streamed Install
adb: failed to install cnfgtest.apk: Failure [INSTALL_FAILED_OLDER_SDK: Requires newer sdk version #34 (current version is #33)]
make: *** [Makefile:191: push] Error 1

This is resolved by setting ANDROIDVERSION=29 in the AndroidManifest.xml target which sets android:minSdkVersion to the lowest SDK version supported by rawdrawandroid.

Fix error: unknown target CPU 'intel' x86 / x86_64 builds
When building the x86 and / or x86_64 target(s) with SDK 34 and NDK 28.0.12674087, the following error occurs:

error: unknown target CPU 'intel'
note: valid target CPU values are: i386, i486, winchip-c6, winchip2, c3, i586, pentium, pentium-mmx, pentiumpro, i686, pentium2, pentium3, pentium3m, pentium-m, c3-2, yonah, pentium4, pentium4m, prescott, nocona, core2, penryn, bonnell, atom, silvermont, slm, goldmont, goldmont-plus, tremont, nehalem, corei7, westmere, sandybridge, corei7-avx, ivybridge, core-avx-i, haswell, core-avx2, broadwell, skylake, skylake-avx512, skx, cascadelake, cooperlake, cannonlake, icelake-client, rocketlake, icelake-server, tigerlake, sapphirerapids, alderlake, raptorlake, meteorlake, arrowlake, arrowlake-s, lunarlake, gracemont, pantherlake, sierraforest, grandridge, graniterapids, graniterapids-d, emeraldrapids, clearwaterforest, knl, knm, lakemont, k6, k6-2, k6-3, athlon, athlon-tbird, athlon-xp, athlon-mp, athlon-4, k8, athlon64, athlon-fx, opteron, k8-sse3, athlon64-sse3, opteron-sse3, amdfam10, barcelona, btver1, btver2, bdver1, bdver2, bdver3, bdver4, znver1, znver2, znver3, znver4, x86-64, geode
make: *** [Makefile:138: makecapk/lib/x86/libcnfgtest.so] Error 1

The fix is to omit -mtune flag or set -mtune=generic where generic is a better choice.

[salihberat]

https://github.com/cnlohr/rawdrawandroid/blob/master/Makefile#L18C1-L27C24

#We've tested it with android version 22, 24, 28, 29 and 30 and 32.
#You can target something like Android 28, but if you set ANDROIDVERSION to say 22, then
#Your app should (though not necessarily) support all the way back to Android 22. 
ANDROIDVERSION?=30
ANDROIDTARGET?=$(ANDROIDVERSION)
CFLAGS?=-ffunction-sections -Os -fdata-sections -Wall -fvisibility=hidden
LDFLAGS?=-Wl,--gc-sections -Wl,-Map=output.map -s
ANDROID_FULLSCREEN?=y
ADB?=adb
UNAME := $(shell uname)

This is resolved by setting ANDROIDVERSION=29 in the AndroidManifest.xml target which sets android:minSdkVersion to the lowest SDK version supported by rawdrawandroid.

i dont see a lowest supported SDK version, and it says:

#We've tested it with android version 22, 24, 28, 29 and 30 and 32.
#You can target something like Android 28, but if you set ANDROIDVERSION to say 22, then
#Your app should (though not necessarily) support all the way back to Android 22.

It is at least supporting SDKs to Android 22, and do you know why application basing Android 34 when the flag is ANDROIDVERSION=$(ANDROIDVERSION) \?

[trholding]

@salihberat

You are correct to point out that ANDROIDVERSION=29 may not be the lowest that rawdrawandroid supports - it must be that I saw in the discord that 29 was the lowest or I must have misread.

The ANDROIDVERSION variable in the AndroidManifest.xml Makefile target is used to substitute this:

	<uses-sdk android:minSdkVersion="${ANDROIDVERSION}"
          android:targetSdkVersion="${ANDROIDTARGET}" />

in AndroidManifest.xml.template and saved as AndroidManifest.xml . (Like filling a form).

@cnlohr What is the actual minsdk that is known to be supported?

[salihberat]

@trholding

[cnlohr]

Are there any Android 34 targets that run x86? Generally, I would not expect x86 to be built in this case.

Same issue as the other PR I just closed (#103) in general, but, if it's strictly for compatibility, I am willing to just get rid of the mtune command, since the difference is likely very small.

[trholding]

Are there any Android 34 targets that run x86? Generally, I would not expect x86 to be built in this case.

Since the -mtune=intel has been probably working fine for <34, maybe just have a commented out line without mtune under a >3X title (need to figure which is the exact value if X) such as:

#Android < 3X? 
CFLAGS_x86:=-march=i686 -mtune=intel -mssse3 -mfpmath=sse -m32
CFLAGS_x86_64:=-march=x86-64 -msse4.2 -mpopcnt -m64 -mtune=intel
#Comment out the above and uncomment the following for Android >= 34? 
#CFLAGS_x86:=-march=i686 -mssse3 -mfpmath=sse -m32
#CFLAGS_x86_64:=-march=x86-64 -msse4.2 -mpopcnt -m64

I had x86 devices (Asus Fonepads 7 & Zenphone 5). And used https://en.wikipedia.org/wiki/Android-x86 on old touch laptops. But those were Android 19 - 22 I think. But existence 34 can't be ruled out - such as chinese Android TV boxes, Tabs and sticks. It is good to have support, but will probably work even without native x86/_64 as they have Intel Houdini https://archive.org/details/androidx86-houdini ARM translation layer.

On a side note I have come across 2 very rare MIPS devices. (I used to have a busybox app in playstore longtime ago and supported all arch binaries in one apk). Lately it seems that NDK support was removed for MIPS and ARMv5. (https://developer.android.com/ndk/guides/abis).

On another note it would be fun to add support for riscv64 on need basis as the beta ndk has support for it already, but probably no devices except SBCs exist... (https://github.com/google/android-riscv64)

My opinion is that it would be nice to have commented out TARGET lines for all ABIs possible, even for the old ABIs supported only by older NDKs: ARMv5 (armeabi) and 32 & 64-bit MIPS. The use case for this small extra effort could be to save old devices from e-trash, for example rawdrawandroid UI dashboards...

But then if these changes seem like they can be avoided, feel free to close this without merging and maybe only add stuff selectively cos I do not have as much foresight about this like you have.

[cnlohr]

I am OK with this change as it stands.