Stack overflow when using google-play source

[tooruu]

OS: Windows 11 (build 26200.8655)
Command run: apkeep -d google-play -a com.delphicoder.flud .
Config file located at %APPDATA%\apkeep\apkeep.ini with CRLF line endings:

[google]
email = myEmail@gmail.com
aas_token = aas_et/...

Program output:

Downloading com.delphicoder.flud...

thread 'main' (29304) has overflowed its stack

One thing to note. I visited the Google embedded setup page to get my OAuth token. After agreeing to the terms, the loading never finished, so I grabbed the token from a POST request to https://accounts.google.com/v3/signin/_/AccountsSignInUi/browserinfo. Passed it to apkeep and it spitted out a normal-looking AAS token.

[gimperioso]

I looked into this and have a reproduction and a fix.

It's a main-thread stack overflow on Windows. main uses #[tokio::main], so the
whole program future is driven with block_on on the process main thread. On Windows the
main thread gets a 1 MiB stack by default (Linux typically ~8 MiB). Downloads go
through gpapi, which decodes the Google Play protobuf responses with prost; those
nested responses are decoded recursively (one frame per nesting level), and for some apps
they recurse deep enough to overflow the 1 MiB stack. That's why it's Windows-specific and
why it hits after auth, right when the delivery info is being fetched/decoded — nothing is
written to disk.

It depends on the depth of the Play response, not the APK size: some larger apps
download fine, while a couple of "busy" listings overflow.

Reproduced on Windows 10 (19045), built from the 1.0.0 tag, google-play source
with AAS-token auth:

Downloading org.telegram.messenger...

thread 'main' (10812) has overflowed its stack

Exit code 0xC00000FD (STATUS_STACK_OVERFLOW), 0 bytes written. Same on
com.instagram.android.

Fix (works): host the Tokio runtime on a dedicated thread with a large stack, instead
of driving it on the main thread:

fn main() {
    const STACK_SIZE: usize = 64 * 1024 * 1024;
    std::thread::Builder::new()
        .stack_size(STACK_SIZE)
        .spawn(|| {
            tokio::runtime::Builder::new_multi_thread()
                .enable_all()
                .thread_stack_size(STACK_SIZE)
                .build().unwrap()
                .block_on(run()); // run() = the former body of main()
        }).unwrap()
        .join().unwrap();
}

With this change the same build downloads org.telegram.messenger and
com.instagram.android successfully. Opened a PR with this change: #246.

One note in case others can't reproduce: an optimized release build with a current rustc
may not overflow (the recursion depth sits right around the 1 MiB boundary, so it depends
on inlining/codegen), but a debug build of the same tag overflows reliably — consistent
with it being a stack-size issue. A deeper fix would be to bound recursion depth when
decoding the Play protobuf in gpapi/prost.