Running native PowerShell 7.6.1 inside an Android APK with no Termux/chroot/proot

[u/MansfieldPlumbing]

Over the last couple days I’ve been experimenting with hosting the raw Microsoft.PowerShell.SDK directly inside a .NET 11 Android APK.

This is not a remote session, SSH client, or Linux container. The PowerShell runspace is running in-process on the Android device itself inside the app process.

Current stack:

• .NET 11 (net11.0-android)
• PowerShell 7.6.1
• React/Vite WebView frontend
• Persistent background runspace
• Single-file HTML applets loaded via iframe shell
• Android ↔ PowerShell bridge over a Base64 JSON IPC layer

A few interesting problems had to be solved to get PowerShell booting cleanly on Android:

• intercepting libpsl-native syslog calls that assume glibc semantics
• bypassing IL trimming issues caused by PowerShell’s reflection-heavy cmdlet discovery
• synchronizing React/WebView startup against the background runspace lifecycle

I documented the details in the repo, including the DllImportResolver interception layer and the Android-compatible stub library used to bypass the syslog crash path.

Repo:
Android-Terminal GitHub Repository

The current direction is less “terminal emulator” and more “PowerShell-native micro frontend environment”:

• applets as standalone HTML tools
• persistent runspace
• Android SAF integration
• PSRP experimentation
• semantic object transport instead of plain terminal text

Still early, but the core runtime is working on physical ARM64 Android hardware today.

Would genuinely appreciate feedback from people familiar with PowerShell internals, hosting, PSRP, or Android runtime edge cases.

[u/Brendan_McCoy]

I don't have any useful feedback in this immediate moment other than to say that I think this is very cool :)

[u/MansfieldPlumbing → u/Brendan_McCoy]

Thank you! I'm kind of excited about it.

[u/ExceptionEX]

You should attempt to publish something through the app store as this likely to raise a lot of red flags as it matches what a lot of nefarious software does 

[u/MansfieldPlumbing → u/ExceptionEX]

I really do hope the powers that be will allow me to humbly stay in my lane so long as I am a polite citizen on Android. It is my intention to publish and release this ad free.

[u/turbokid → u/MansfieldPlumbing]

If you are releasing this, how are you ensuring you arent just giving hackers an easy repository to hack android? Just because you "stay in your lane", doesnt mean any of your customers will.

[u/dodexahedron → u/turbokid]

Wouldn't it be just as easy, if not easier (and more capable), for an attacker to just use plain .net rather than layering powershell on top of it?

While I get where you're coming from, I also do think it falls into the same category of "vulnerability" as having any kind of public API surface which, of course, there already is or it would be a somewhat restrictive platform in general.

[u/turbokid → u/dodexahedron]

My point wasnt that attackers dont have other attack vectors, its more that its introducing a new execution surface (webview - IPC - Powershell) that doesnt currently exist. Powershell is also easier to write, so it lowers the barrier of entry, which allows people like script kiddies to use this. Any good public API has been hardened over time. What does this particular method bring that overrides the concern this will be used nefariously?

[u/ExceptionEX → u/dodexahedron]

its about obfuscation of what is being done, and getting that past the appstore's security checks, its why this sort of activity is already red flagged.

[u/node77]

Yeah, I used Termux for that once. It sort of worked. The PowerShell runtime should be included in some IDE like Python.

[u/unumri]

That IL trimming and AOT compatibility story is the part I'd lose sleep over, reflection-heavy, SDK hosting and aggressive trimming are a rough combination, and PowerShell's internals lean hard on reflection. Also worth flagging that. NET 11 isn't a current stable release, so curious whether that's a preview build or a typo in the post.