* Support non-integer API level
* update lib
* Add test
* No need to install platforms.
Mostly application will use different SDK platform.
* Update lib
* Add `pre-emulator-launch-script` to `action.yml`
* Add `pre-emulator-launch-script` in `main.yml`
* Implement pre emulator launch script
* Try to use `pushd`
* print working directory
* Add `README`
* Run `npm run build`
* Fix `working-directory`
* Run `npm run build`
* Run pre emulator launch in group
* Run `npm run build`
* Update README.md
Co-authored-by: Yang <reactivecircus@gmail.com>
* Add type "pre-emulator-launch-script"
Co-authored-by: Yang <reactivecircus@gmail.com>
* Update build-tools to 31.0.0. Add API 31 emulator to workflow. Update SDK command-line tools to 5.0
* Update test fixture dependencies.
* Test API 31 with macos-11.
* Add android:exported to AndroidManifest.
* Format
* Add non-mobile targets to allowlist
* Add new targets to input validator tests
* Update built input-validator.js
* Update README with new targets
* Update action.yml with new targets
The exec() command only runs a program with literal argument strings.
It does not know how to do things like expanding environment variables,
or piping/redirection. Hence the way to get "shell intelligence"
is to use exec() to run the `sh` process with the command line string
as a parameter.
But the method being used to do this was:
exec.exec(`sh -c \\"${script}"`)
This has problems, because wrapping the script in quotes creates
issues when the script itself contains quotes. Escaping the string
correctly is a non-trivial problem, which also would create "noise"
in the debug output which would add confusion.
http://mywiki.wooledge.org/BashFAQ/050
The easiest way to work around this here is to use the array form of
exec() to pass exactly two parameters to `sh`. No manipulation of the
script string is needed with this approach:
exec.exec("sh", ["-c", script])
There are more cases in the project of `sh -c` usage which should also
be changed, and likely abstracted (shellExec()?) But this small patch
just fixes the most important case for the user-provided script.
---
Additionally, this removes the escaped backslash (`\\`) from the
start of the executed command. That was presumably to suppress the
use of aliases:
https://unix.stackexchange.com/questions/524254/why-are-backslashes-included-in-this-shell-script
But because this is invoking a non-interactive shell session, aliases
would not apply. Hence the extra backslash shouldn't be needed.
Josh Lesch