クライアントとサーバーのみの場合は、何も購入せずに相互認証されたSSLを使用できます(使用する必要があります)。サーバーとクライアントを制御するため、それぞれが1つの証明書のみを信頼し、一方は他方に属し、この目的のためにCAは必要ありません。
これが高レベルのアプローチです。自己署名サーバーSSL証明書を作成し、Webサーバーに展開します。この目的のために、AndroidSDKに含まれているキーツールを使用できます。次に、自己署名クライアントを作成し、それをアプリケーション内のリソースとしてアプリケーションに含まれているカスタムキーストアにデプロイします(keytoolもこれを生成します)。クライアント側のSSL認証を要求し、生成したクライアント証明書のみを受け入れるようにサーバーを構成します。そのクライアント側の証明書を使用して自身を識別し、サーバーにインストールした1つのサーバー側の証明書のみをその部分に受け入れるようにクライアントを構成します。
このためのステップバイステップの答えは、ここで保証されているよりもはるかに長い答えです。サーバー側とクライアント側の両方でAndroidで自己署名SSL証明書を処理する方法についてのリソースがウェブ上にあるため、これを段階的に行うことをお勧めします。O'Reillyが発行した私の本「Androidプラットフォームのアプリケーションセキュリティ」にも完全なウォークスルーがあります。
通常、その証明書/秘密鍵を何らかのタイプのキーストア(Androidを使用している場合はKeyStore)に保存し、そのキーストアは暗号化されます。その暗号化はパスワードに基づいているため、(1)そのパスワードをクライアントのどこかに保存するか、(2)ユーザーがクライアントアプリを起動するときにパスワードを要求する必要があります。何をする必要があるかは、ユースケースによって異なります。(2)が受け入れられる場合、クレデンシャルは暗号化され、パスワードはどこにも保存されないため、リバースエンジニアリングから保護されています(ただし、ユーザーは毎回パスワードを入力する必要があります)。(1)を実行すると、誰かがクライアントをリバースエンジニアリングし、パスワードを取得し、キーストアを取得し、秘密鍵と証明書を復号化して、サーバーに接続できる別のクライアントを作成できるようになります。
これを防ぐためにできることは何もありません。コードのリバースエンジニアリングを(難読化などによって)難しくすることはできますが、それを不可能にすることはできません。これらのアプローチで軽減しようとしているリスクとは何か、そしてそれを軽減するためにどれだけの作業を行う価値があるかを判断する必要があります。