Improve windows and androidx compatibility

[omar-azmi]

I was having difficulties getting the scripts to run in windows git-bash, and a lot of it had to to with path strings. This PR improves the compatibility of the scripts with windows, and can also compile projects with dependencies (such as androidx).

Overview of the changes made:

• set API_LEVEL to 28, as the final make.sh script fails during compilation at higher api level. possibly related to #4 .
• modify the bash variables in include.sh, so that they reflect windows paths and commands, rather than linux's .
• escape all paths in all scripts with double quotation marks (\" ... \"), instead of single quotation (' ... '). this is because paths begining with a single quotation and ending with one are perfectly valid in windows, thus making the intended paths incorrect.
• in export-libs.pl, make sure that files are opened in binary mode rather than text. without binmode($fh);, the resource pngs of androidx were getting corrupted due to their eighth magic byte (0x0A or "\n") being re-encoded as CRLF (0x0D0A or "\r\n").
• in make.sh:
  • place the path to android.jar at the top, otherwise java fails to import the android classes in our MainActivity.java, because they were not defined prior.
  • reduce javac compilation source and target from 11 to 8, otherwise a compilation error is thrown. this could be due to the fact we previously compiled the linked libraries using target 8, in link.pl.
  • ignore kotlin compilation altogether, as I couldn't find a suitable shell command in windows that will not throw an error if not kotlin source files are found by the find command ($CMD_FIND_SRC_KOTLIN).
• add .gitignore to ignore leftovers from building.

Fixes to consider before merging:

• The shell variables in this PR certainly need to be modified back their neutral linux commands state. However, I don't know which ones should be reverted back. I'll probably be reasonable to keep os-specific commands mentioned in the comments, so as to not confuse the end user too much.
• Kotlin compilation will need to be re-enabled, without causing issues in windows when no kotlin source files are found.
• Should .gitignore be removed?

[omar-azmi]

Thanks for the indepth review, and also for the handy tool. Initially, I was mostly having issues getting the scripts to run on windows due to inconsistency between bash and cmd commands. But I realize now that this issue stems from the fact that executing a bash script via cmd redirects it to git-bash, which supports all bash commands, therefore no substitutions to your original $CMD variables is needed. but executing a pearl script via cmd, makes it run in the command-prompt environment, where bash commands will not be available. So, for consistency, a user should ideally run all of the scripts (.sh and .pl) in a bash terminal. This way, they won't have to redefine the command variables (including "/dev/null", which works on windows git-bash). Alternatively, we could modify the perl scripts so that they make use of builtin filesystem procedures, rather than calling system commands for trivial operations. This way, all scripts will function just fine irrespective of whether they were originally launched from cmd, or bash.

So, a summary of what I plan on changing in the followup commits:

• [x] revert all command variables back to their original bash form.
• [x] place a comment somewhere to inform users that they would need a bash terminal installed for the bash scripts to work (suggest git-bash for windows).
• [x] modify the perl scripts to use platform independent filesystem operations, rather than executing terminal commands.
• [x] re-enable kotlin source file search.
• [x] try out --release 8 for java compilation.
• [x] remove NUL from .gitignore, which currently gets created when $DEV_NULL = NUL, and a bash script that utilizes that variable is ran.
• [x] remove hardcoded SDK build-tool version path. and maybe add two version specifiers for the API version: one for the build-tools (which may be semantically versioned), and the other for the platform (which, I believe, is always an integer).

[omar-azmi]

I've applied your suggestions, and it works fine on my machine, irrespective of whether I envoke the scripts from cmd or bash. I think it is good to go. would you mind testing it yourself and accepting the PR if it's not causing any issue? let me know if any changes need to be made.

[jbendtsen]

Looks good! I've tested it on my Windows machine and it works well. Nice touch with the bespoke recursive copy function in export-libs.pl. Thank you!