Genのプログラム日誌 主にAndroidについての備忘録

Google Playの課金周りの処理はよく分からない

私はスマホにアカウントを2つ登録して使っている。メインのアカウント（以降Aと呼称）とゲーム用のアカウント（以降Bと呼称）って言う感じで分けているのだ。

で、そうやってアカウントを2つ使っていると、ゲーム内課金を行うときにちょっと困ったことが起こる。課金するアカウントにどっちが選ばれるか問題である。

Read full post gblog_arrow_right

ランタイムパーミッションの対応をするとActivityがマッチョになるのなんとかならんかな

Android6.0からアプリのインストール時ではなく、パーミッションを必要となる操作を行う前に許可を求める形式になった。これ自体はとてもよいこと。インストール時にやたら権限を要求するアプリがなんだか怖くてインストールすらしなかったのが、これのおかげでとりあえず試して見れるようになったのはとてもよい。

Read full post gblog_arrow_right

Crashlyticsのクラッシュレポートをdebugビルドでは行わないようにする

新しいアプリを作るときにしかやらないので、いつもやり方を忘れてしまうCrashlyticsのレポート設定のメモ。 デバッグビルドでまでクラッシュレポートが報告されてしまうと、通知がうっとうしいだけですし、手元でスタックトレースが読めるわけですから完全に無駄です。必要なのは基本的にはリリースビルドだけでしょうから、開発中は無効にしてしまうのが便利です。 やることは下記のページのとおりです。 https://docs.fabric.io/android/crashlytics/build-tools.html?gradle#build-tools まずはレポートを無効にしたいbuildTypeにext.enableCrashlytics = falseを追加します。 この設定はGradleのビルド時に、Crashlyticsで使うIDなんかを生成する処理を行わないようにするもののようです。レポート送信を止めるわけではないので、これを追加しただけでは下記のようなエラーが出てしまいます。 This app relies on Crashlytics. Please sign up for access at https://fabric.io/sign_up, install an Android build tool and ask a team member to invite you to this app's organization. 開発時にレポート送信自体を止めるためには、アプリ実行時にCrashlytics自体が動かないようにする必要があります。そのためには、Crashlyticsの初期化を行う部分で、下記のように初期化を行います。 Crashlytics crashlyticsKit = new Crashlytics.Builder() .core(new CrashlyticsCore.Builder() .disabled(BuildConfig.DEBUG).build()) .build(); Fabric.with(this, crashlyticsKit); ちなみにdebuggableがfalseなんだけどCrashlyticsのレポートを無効化したい、なんていう場合には、.disabled(BuildConfig.DEBUG || BuildConfig.BUILD_TYPE.equals("test"))のようにしてやればOK。 レポートが送信されないことの確認 アプリの任意の場所でthrow new RuntimeException("Crashlytics report test");と例外を投げてみればOK。 ただし例外を投げる場所に注意が必要です。Crashlyticsの初期化が終わっていないと、そもそもレポートが送信できません。Applicationクラスの外か、ActivityのonCreateの外で例外を投げるようにしないとテストにならないので注意しましょう。 https://docs.fabric.io/android/crashlytics/introduction.html

CapabilityAPIを使う場合、アプリのパッケージ名に注意

Android Wearのアプリを作成する際には、パッケージ名をスマホ側と同じにしなければなりません。 新規プロジェクトで初めからWear用のアプリも含めて開発する際は関係ない話です。Android Studioの新規プロジェクトウィザードでターゲットにWearを追加するだけなので、両者のパッケージ名を別のものにしようと思ってもできません。 気をつけなければならないのは、スマホ用のアプリを作成していて、途中からWear用のモジュールを追加する場合です。「Wear用のモジュールだからパッケージ名変えたほうがいいかな」なんて気を利かせると逆にハマります（私のように）。 （ちなみにここで言っているパッケージ名は、アプリのパッケージ名のことです） 開発時はWear用のモジュールを実行、スマホ用のモジュールを実行という感じでアプリをインストールして実行できるので問題に気づきにくいのですが、Wearとスマホで通信を行おうとした際にハマります。 具体的にはCapability APIを使って通信可能なノードを取得する際に、パッケージ名が違うとそのノードが取得できません。 https://stackoverflow.com/questions/35136881/cant-detect-node-using-the-capability-api Capability APIはWearからの要求に応答可能なデバイスを探すための仕組みです。例えば自分で 「say_helloという要求を行う」と定義しておけば、Wearからメッセージを送信する際にsay_helloが定義されているデバイスだけを、Capability APIを使うことによって取得することが出来るのです。しかし、それはパッケージ名が同じアプリであればの話です。 ちなみにNode APIを使えばパッケージ名が異なっていようが関係なく、ペアリングされているノードが取得できます。パッケージ名が異なると接続されているノードが取得できないのはCapability APIを使った場合の話のようです。 Wearアプリを作成する場合、パッケージ名を変えることは基本的にはないと思いますが、Wearのパッケージ名とスマホのパッケージ名を異なるものにすると弊害があるぞというお話でした。特に後からWear用のパッケージを追加するときには気をつけましょう。

Bluetooth経由でデバッグする

Android WearデバイスをBluetooth経由でデバッグする方法について。 Android WearもUSB経由でパソコンに接続してデバッグする方が何かと便利です。ですが、USB経由で接続しようと思うと、Wearデバイスに直接USBケーブルをつなぐタイプのものなら問題無いでしょうが、クレードル経由で接続するタイプの製品だと腕につけた状態でデバッグできません。 そんなときはBluetooth経由でデバッグすると便利です。 https://developer.android.com/training/wearables/apps/bt-debugging.html Android Wearでの事前準備 Bluetooth経由でのデバッグを有効化しておく必要があります。 まず設定→端末情報→ビルド番号を7回タップして開発者オプションを有効にします。 すると開発者オプションを選択できるようになるので、そこからADBデバッグとBluetooth経由でデバッグを有効にします。 以上でWear側の事前準備はOK。 スマホ側での事前準備 Android Wearとペアリングしているスマホ側でもBluetooth経由のデバッグを有効化してやる必要があります。 Android Wear companion app（日本語だと単にAndroid Wear）を実行します。Android Wearとのペアリングしたりするアプリです。 使いたいAndroid Wearデバイスとのペアリングした状態で、Appbarにある歯車アイコンを押します。 すると設定画面が開くので、その一番下にあるBluetooth経由のデバッグを有効にしてやります。 ホスト：未接続、ターゲット：接続済みとなっていると思います。 それができたら次のステップ。 パソコンからターミナルで操作 以下のコマンドを実行。 adb forward tcp:4444 localabstract:/adb-hub adb connect localhost:4444 adb connect localhost:4444でConnection Refuesedとなってしまう場合、localhostの部分を127.0.0.1とすれば接続できると思います。 接続できればスマホで「ホスト：未接続」となっていた部分が「ホスト：接続済み」となると思います。 そうすればAndroid StudioからAndroid Wearデバイスが見えるようになっていると思います。 切断 adb disconnect 127.0.0.1:4444 adb forward —remove tcp:4444 ちなみにポートフォワーディングしているかどうかを確認するにはadb forward —listで確認可能。 もっとも、スマホのUSBケーブルを抜くとそのままBluetooth接続も解除されるので、わざわざ上記コマンドを叩いて切断する必要はまったくありません。 注意点 Bluetooth経由のデバッグでも、デバッガでブレークポイントを設定したりステップ実行したりすることができます。ただし、USB経由でのデバッグと比較すると格段に遅いです。 アプリのインストールもBluetooth経由で可能ですが、やっぱりUSBで繋いだ時と比べると遅いです。 ケーブルレスでデバッグできるのは便利なのですが、可能であればUSBで実機をつないでデバッグした方が開発サイクルを早く回すことが出来ると思います。 Bluetooth経由のデバッグは、Wearを腕にはめた状態でないと出来ない動作の確認（センサーを使った動作のデバッグ）などに限定して使ったほうがいいと思います。 ちなみにBluetooth経由のデバッグを有効にした状態で、WearをUSBで直接パソコンにもつないでおくと、WearデバイスはBluetoothで接続したものとUSBで接続したもの2つが見える状態になります。

久しぶりにAndroid Wearの電源を入れた

私はLG G watch Rを持っていたのだけれども、長いこと使っていなかった。普段腕時計をしないし、するにしても薄くて軽いやつをずっと使っていたので、スマートウォッチの大きさが我慢できず、そのうちつけるのをやめた。

そんな放置していたスマートウォッチを久しぶりに使ってみた。

Read full post gblog_arrow_right

暗号化について勉強中

Androidでユーザデータを暗号化して保護するにはどうしたらいいのでしょうか。 これまで「暗号化のやり方がよくわからないから、機密情報を保存しないようにしよう」と避けてきたのですが、それにも限界があるのかなぁと思って、手を広げてみる気になったのです。 まあ本当の出発点は、ユーザデータの保護ではなく、アプリで扱うデータを秘匿するにはどうしたらいいのだろうだったんですけれど・・・。 例えば、Twitterクライアントを作るとして、そのAPIキーをどうやって秘匿するのかということです。 Androidでこの手のAPIキーを扱う場合、サンプルではJavaのコードに直接書いてありますが、実際に自分でリリースするアプリでもそのままでいいのかという話です。 AndroidではAPKを簡単に抜き出して、しかも簡単にソースコードを確認することもできます。ProGuardで難読化をしても、Javaのコードに埋め込んだ文字列はそのままです。 String api_key = "hogehoge";のapi_keyの部分はProGuardによってaとか意味のない文字に書き換わりますが、”hogehoge”の部分は書き換わりません。（書き換わったらプログラムの動作が変わってしまうので当たり前です） つまり、やろうと思えばAPIキーは見放題ということになります。 だからここの部分、どうするのがセオリーなんだろうってのから始まって、暗号化すれば秘匿できるのかなと思ってみたのです。 多分、ユーザに見せたくないデータはアプリで保持しないのが正解であって、暗号化は関係ないと思いますが、それでも今まで放置していた暗号化に関して勉強するいい機会ではあるのでそのまま続けております。 どう勉強してるのかって話ですが、https://developer.android.com/training/articles/keystore.htmlを見たり、Android Studioのimport Sampleで取り込めるGoogleのサンプルコードを使ったりしてます。 実際に手を動かしてみて初めて知ったのですが、同じ文字列を同じ暗号化鍵で暗号化しても、得られるバイト列が毎回異なることに驚きました。”abc”を同じ暗号化鍵を使って暗号化したら、毎回123になるというイメージを持っていたものですから、なんで毎回異なるバイト配列になるのか不思議です。しかも異なるバイト配列になるのに、復号化したらちゃんと”abc”に戻るのですからなお不思議です。 これは一体どういう仕組なのか。そもそも暗号化の仕組みを理解せずに使うのは逆に危険なんじゃないのかと思い始め、今度はこんな本を読み始めました。 暗号技術入門 第3版 秘密の国のアリス posted with ヨメレバ 結城 浩 SBクリエイティブ 2015-08-26 Amazon Kindle 紀伊國屋書店 まあまだ読んでいる最中なんですけど面白いです。 本書には 弱い暗号は暗号化しないより危険である という考え方が序盤で紹介されています。仕組みを理解せずに暗号化するのもまた良くないと言えるのではないでしょうか。 安定の結城先生なので非常に分かりやすく、楽しく読めそうです。 それにしても、初めはAPIキーを秘匿することがきっかけだったのに、我ながらよく脱線してきたものだなぁと思います。
1 min read