Chess for Android Release (API30 complaint)

[abik]

In my CT800 engine, I'm throttling UCI_Elo via absolute node rate, and that works regardless of the hardware, also under Android.

That is an interesting idea. Sort of how C64 emulators remain more or less cycle accurate even on different architectures?

[Ras]

would you be willing to package the CT800 engine into an OEX or CB compatible app?

I wouldn't even know how to do that. Right now, I'm treating Android as a POSIX platform just like regular Linux, only that the build script points to the NDK toolchain. That's why it's so easy to have an Android version, as byproduct of targeting Linux anyway. The whole I/O is via raw read/write, bypassing even the C standard library.

If licensing allows, I could also package the engine

That would be perfectly fine as long as the GPLv3 is observed.

That is an interesting idea. Sort of how C64 emulators remain more or less cycle accurate even on different architectures?

Basically, I allocate the desired node rate as node budget for each second. If the budget is spent, the engine sleeps for the remainder of that second. The nice thing is that this also works with dynamic CPU clocking where the first 20ms after waking up from sleep, the CPU is still clocked down because the scheduler needs to see a certain amount of work before deciding to ramp up the speed. As for the top end, I'm calibrating the machine speed at startup to see what node rate it can do, but that's currently buggy and instead uses the fallback assumption of 1MNPS.

[abik]

That would be perfectly fine as long as the GPLv3 is observed.

Lacking a formal legal training, I am not sure for this particular case if shipping a licensed engine in a packaging module transfers the license requirement to the container code as well. All my software is original, including the CB packaging container, but not open source. Alternatively, I could move away from CB towards the open source OEX and avoid such complications. Or perhaps other chess engine packaging authors that already solved this issue are willing to make life easier and pick up CT800?

[Ras]

Lacking a formal legal training, I am not sure for this particular case if shipping a licensed engine in a packaging module transfers the license requirement to the container code as well.

That depends on the nature of the container, i.e. whether it is an aggregate work with static linkage, or rather like a dynamic plugin system. If the engine can be changed on the fly, then it's a plugin system with no licence spread. If, on the other hand, changing and updating the GPL'ed engine parts is not something a user can do at all, then it's an aggregate work so that the licence would spread. That's not just for the CT800, but also e.g. for Stockfish.

Alternatively, I could move away from CB towards the open source OEX and avoid such complications.

The problem is that with this way, you still cannot just have a C/C++ engine and recompile. You suddenly have to enter Java app programming just to get it working on Android. That's a massive barrier, and it will not stop there. I still say, promote the F-Droid store instead which doesn't have the API30 problem in the first place. Otherwise, chess under Android will become just as sparse as under iOS.

[abik]

That's a massive barrier, and it will not stop there. I still say, promote the F-Droid store instead which doesn't have the API30 problem in the first place.

I understand where you are coming from, I really do, but, I, for one, would like to remain loyal to Google Play for just a little longer. The loss of install from SD card was very disappointing, but the solution through packages still works well (and in fact, although it is harder on the person shipping the engines, it is much easier for the user importing the engines in the end). The new file permissions was a lot of work, but even there user experience in the end probably improved with better control on what app can read and write where.

Otherwise, chess under Android will become just as sparse as under iOS.

Luckily my day job involves compiler support for sparse tensor computations, so I am no stranger to sparsity

[Ras]

although it is harder on the person shipping the engines

The only reason why there even are many mid-range chess engines for Android is because it's just a recompile. Right now, F-Droid is the escape hatch, but if Google should decide to tighten that on OS level instead of the store, I'd simply drop the support for Android - and I'd hardly be the only one. It's just not worth the effort if you aren't already into Android app development. Also, I'm not interested in proprietary, locked-down platforms (which is why my engine has no iOS port).