@FormUrlEncoded

Oi Francisco, blz?

Olhando a sua config, parece que tá tudo certo, era pra funcionar. Até conferi na documentação e é usando o @FieldMap que da pra garantir...

Aparece alguma coisa no logging interceptor?

Esse é o log que é mostrado:

07-16 10:39:40.998 15445-17429/br.com.transire.vanecontrol D/OkHttp: --> POST https://ghost-market.herokuapp.com/v1/oauth2/token
    Content-Type: application/x-www-form-urlencoded; charset=utf-8
07-16 10:39:40.999 15445-17429/br.com.transire.vanecontrol D/OkHttp: Content-Length: 63
    password=123&grant_type=password&username=brennohd9%40gmail.com
    --> END POST (63-byte body)
07-16 10:39:41.850 15445-17429/br.com.transire.vanecontrol D/OkHttp: <-- 400 Bad Request https://ghost-market.herokuapp.com/v1/oauth2/token (850ms)
    Server: Cowboy
    Connection: keep-alive
    X-Powered-By: Express
07-16 10:39:41.851 15445-17429/br.com.transire.vanecontrol D/OkHttp: Access-Control-Allow-Origin: *
    Cache-Control: no-store
    Pragma: no-cache
    Content-Type: application/json; charset=utf-8
    Content-Length: 87
    Etag: W/"57-dlHCONIvjCacCwUTUOdGFAjz01g"
    Date: Mon, 16 Jul 2018 14:39:41 GMT
    Via: 1.1 vegur
07-16 10:39:41.854 15445-17429/br.com.transire.vanecontrol D/OkHttp: {"code":400,"error":"invalid_grant","error_description":"User credentials are invalid"}
    <-- END HTTP (87-byte body)
07-16 10:39:41.857 15445-15445/br.com.transire.vanecontrol I/onResponse: requisição com sucesso

Eu estou tirando conclusões com base nessa linha:

password=123&grant_type=password&username=brennohd9%40gmail.com

Oi Francisco,

Eu fiz uma pesquisa e vi que no logging interceptor vai aparecer assim mesmo, porém, no server, vai enviar os dados como esperado. Acabei de testar em uma api que montei de teste e ela recebeu o dado com o caracter esperado usando apenas a annotation @FormUrlEncoded.

Você tem acesso a API para verificar como o dado está sendo recebido?

Isso é verdade, o server envia os dados como esperado, porém na hora do realizar o login o mesmo informa que os dados estão inválidos. Acredito que seja pelo motivo que esteja trocando os caracteres.

Nesse caso precisa confirmar como o server está recebendo os dados, pois com o teste que eu fiz ele recebeu conforme esperado... Caso não tenha acesso ao server, faça o seguinte, tente simular a mesma requisição usando o Postman, se apresentar o mesmo problema, significa que tá acontecendo alguma outra falha que não é do formato.

Eu já havia realizado o teste usando o postman.

Eu conseguir efetuar a requisição com sucesso seguindo as alterações:

@FormUrlEncoded
    @POST("oauth2/token")
    @Headers("Content-Type: application/x-www-form-urlencoded; charset=utf-8")
    Call<TokenResponse> login(
            @Field("grant_type") String grantType,
            @Field("username") String username,
            @Field("password") String password
    );

Credentials credentials = new Credentials("sfrancisco51@ymail.com", "123");

        Call<TokenResponse> call = new RetrofitStarter().getUserService().login(
                credentials.getGrantType(),
                credentials.getUsername(),
                credentials.getPassword()
        );
        call.enqueue(new Callback<TokenResponse>() {
            @Override
            public void onResponse(Call<TokenResponse> call, Response<TokenResponse> response) {
                Log.i("onResponse", "requisição com sucesso");

            }

            @Override
            public void onFailure(Call<TokenResponse> call, Throwable t) {
                Log.e("onFailure", "requisição falhou");

            }
        });

Muito obrigado pela atenção!

No interceptor logging, usando o @Field apareceu o caracter especial também?

Sim apareceu, porém a requisição retornou o resultado esperado, enquanto que usando a forma anterior era retornado a mensagem: "Credenciais inválidas".

Que estranho kkkk

Ainda bem que no final deu certo hehe

Valeu Francisco :)