gpipipi
=======
a rust crate for the google play api
[](https://crates.io/crates/gpipipi)
[](https://docs.rs/gpipipi)
usage
-----
you get an oauth token by logging in into the [embedded setup page](https://accounts.google.com/EmbeddedSetup), opening the dev tools and then checking the network tab / application tab for the returned cookie. the token can only be used once, and the resulting aas token doesn't seem to expire
after getting the oauth token, you can convert it with the crate by running it as a binary like so:
```bash
OAUTH_TOKEN="..." EMAIL="..." cargo run --features binary
```
alternatively you can convert it manually using [OAuthRequest](https://docs.rs/gpipipi/latest/gpipipi/struct.OAuthRequest.html)
after getting the aas token, you can now log in and start doing requests using [LongLivedClient](https://docs.rs/gpipipi/latest/gpipipi/struct.LongLivedClient.html)
if you already have an auth token that was generated from an aas token somewhere else, use [ShortLivedClient](https://docs.rs/gpipipi/latest/gpipipi/struct.ShortLivedClient.html) instead, auth tokens expire way faster than aas tokens do and that client has no aas token to renew them with, so it takes a fresh one whenever you have it
the requests themselves live on the [Client](https://docs.rs/gpipipi/latest/gpipipi/trait.Client.html) trait, which both of them implement, so it needs to be in scope
tests
-----
the doc examples log into google for realsies, so they need tokens of their own, and they take a different one than the binary does `AAS_TOKEN` is what comes out of it
```bash
EMAIL="..." AAS_TOKEN="..." cargo test
```
since every example logs in on its own, google likes to throttle them when they all run at once, `--test-threads=1` sorts that out
credits
-------
- [**gplayapi**](https://gitlab.com/AuroraOSS/gplayapi)
- [**gpapi**](https://github.com/EFForg/rs-google-play/tree/master/gpapi)