To make android build through p4a work in native Windows without WSL2/ VirtualBox etc

[Samael-TLB]

Description

Currently, p4a can only build for android on Linux OS. For usage through Windows, its suggested to use either WSL2 or VirtualBox, etc. But, on reviewing the internal codebase, it seems we can support native Windows build for android without using any hacks. We have to just have the commands issued to the shell to be platform compliant. Either we can use cmd or powershell for that. The only other part that I am not fully covered up for to achieve this , is the requirements of p4a. Once, we can figure the list of dependencies that might be needed for native Windows or can port the Linux dependencies counterparts for Windows, we can safely have native Windows build for android.

To further support the claim, we can see that beehive project supports android building natively without any OS specific dependencies(beg to differ?). Also, as we are using the cmdline-tools to build for android and as these tools are also released for Windows by Android project so we can safely do the compilation on native Windows.

Moreover, this feature will help a lot of Windows user who may be unfamiliar with Linux or WSL2 and they can just as comfortably do the build without doing anything specific, just like how Android Studio does it on Windows. This will give extra ease of use and for future, we can have a cross-platform Android Studio like project using Kivy resources for build.

Also I have added the relevant feature request upstream for buildozer #kivy/buildozer/issues/1651. Together, these two shall solve the issue.

[Android-for-Python]

I disagree, here is why (of course you can use your time any way you please):

• In these days of Windows Terminal the difference between two shells (Bash or Cmd) is a tab, so it is not obvious that the proposal adds user utility. All a user needs to know is how to copy between partitions. File Explorer is partition agnostic, at least for basic operations. We do have issues with users who can't follow install instructions, but users who can't type buildozer or cp - not so much.

• Long term support costs for Buildozer and p4a are not considered. This would be more OS specific code to support, another OS to validate on a release, another set of OS specific issues. We already have more features than can be supported - just look at the PR or Issue lists.

• Some (pure) Python packages have OS specific setup, they install different assumptions depending on OS. It is not clear that a package installed using a Windows hostpython will work correctly on a Linux-like Android targetpython. [Hostpython exists because of a similar issue with Python versions.] We already sometimes see this when WSL users build on the Windows partition. This occurs because Python has I think 3 ways to detect the OS, one of those (in part) looks at the disk format. So with p4a we see a package built on NTFS may not be correctly installed in an apk.

• Linux links are not well supported on NTFS, p4a could probably be OK, but other programs such robocopy can get very confused. This creates 3rd party issues.

• Comparisons with Beehive are meaningless without a descriptions of its internal architecture, or metrics of any known issues. It is possible Beehive is perfect, but to support that an explanation of why is required.

• The idea that if we just had some particular feature the project would be wildly successful, is self justifying and unverifiable. Discussion of what would make the project more successful would be valuable.

[Julian-O]

I have been looking at this issue recently. As I have explained on the linked Buildozer issue, my development motto has been "It probably won't happen in my lifetime, but I want to make it possible in my grandchildren's lifetime."

I realise that there is a somewhat dismissive attitude to its importance amongst the core Linux developers, so I have been trying, where possible, to make sure that there are improvements to the overall code to make the changes more palatable. e.g.

• Use platform.uname instead of os.uname #2857 got rid of a totally unnecessary platform dependency, but also made the code slightly cleaner.
• Automatically generate required pre-requisites #2858 simplified the code for all existing platforms, but also allows new platforms to be added more easily.
• Standardise ensure_dir and rmdir #2871 (still under review) makes the code more consistent and gives a performance boost, but, more importantly, also removes a number of unnecessary platform dependencies. Once it is merged, I have a string of similar PRs to tackle other unnecessary dependencies.

So far, these have been the easy parts. I do not yet have answers on how to deal with the far more difficult hurdles ahead (and I don't promise to be able to deal with them all before I give up - just to push closer for the next person to try.)

---

As for the objections above:

• I can't emphasize enough how having to be an administrator of yet another operating system, with yet another set of conventions is more than just "a tab". I don't think I am exaggerating when I say it adds 20% to the cost of my project. I understand other people have different levels of experience and have different tolerance to having to change context mid-development, but for me having to spend half-a-day on getting VirtualBox to increase its drive space to allow an upgrade, or half-a-day on working out how to get my Android device to connect to the virtual USB (and failing), and constant context shifts because I can't just hit a button in my IDE to do a complete build and deploy, adds up to a lot. The difference between Windows and Android (and Python and Java) is bad enough without adding Linux to the mix.

• Yes, this would mean another platform on the test matrix. Plus there would be the cost of code churn introducing bugs, and reviewer time. I don't want to diminish this. I have been trying to make sure that my changes (e.g. on Buildozer), overall, lead to cleaner code with better testing to make this pill more easy to swallow.

• As you point out, NTFS doesn't support symbolic links. I expect that to be a hurdle to overcome, but I feel reasonably confident about that one not being a show-stopper. (Running configure and make scripts has me more concerned!)

• I think it is reasonable to expect that we may need some Windows-only recipes for poorly-behaving pure Python installations. I haven't seen examples of these yet, so I don't know much about what to expect. Until those recipes are in place, we may need to simply shrug and say "PackageX on PyPI is not yet supported on native-Windows p4a."

• I can't guarantee that native Windows support would be wildly successful, but I can say "It would fix my pain points" and it sounds like I would be supported by @Samael-TLB here, so there must be dozens of people us! :-)

[Samael-TLB]

I totally agree with your views @Julian-O and would surely love to support you in this endeavor. Moreover, if we can prove the benefit through actual implementation, then may be the core Linux developers may have open views regarding the same. Also, I have been doing some research on the issues with Windows, Python and Android cross-compilation over the last week. And based on that it seems that as Android supports building apps natively in Windows and as also that encompasses the usage of the NDK for JVM access through JNI and C/C++ side, we can definitely pull this off successfully in due time basing ourselves on the foundation of enormous work that have already been done in Kivy. Also, due to the recent PEP 720, it seems that python community may be heading towards making python and all of its modules and packages cross-compilable in a seamless manner. Moreover, @Julian-O , please do collaborate with me, so that we can tackle this issue together.

[Julian-O]

@Samael-TLB: You can find me on the Kivy Discord server as ".julian_o". Let's chat about what is feasible and what the first steps are.

[Samael-TLB]

@Samael-TLB: You can find me on the Kivy Discord server as ".julian_o". Let's chat about what is feasible and what the first steps are.

Sure @Julian-O