読者です 読者をやめる 読者になる 読者になる

中年エンジニアの開発と生活の日々

中年エンジニアがソフトウェア開発や日々の生活で得た知見の備忘録

appium-desktop を Android アプリで使ってみる

先日 appium-desktop を紹介しましたが、Android 編のリクエストがありましたので、追加して見ました。

android で appium-desktop を使う利点

android については 古い desktop 版の appium Ver.15.x でも Inspector 機能を使うには支障がなかったため、appium-desktop 必須という訳ではありません。 しかしながら、設定パラメータの与え方などは appium-desktop の方がコマンドライン版に近いため、appium-desktopの方が断然オススメです。

アプリケーションの起動からサーバーの起動まで

アプリケーションの起動からサーバーの起動までは全く iOS と同じです。

Session を起動する時の注意

iOSアプリでは事前に Simulator を起動しておく必要はありませんが、Androidアプリを動作させる時はコマンドライン版と同じように、エミュレータをあらかじめ起動しておく必要があります。 エミュレータコマンドラインからでも Android Studioから起動しても同じように動作します。

Desired Capability

Desired Capability はコマンドライン版と同じオプションを指定しておく必要があります。 - platformVersion - 起動してあるエミュレータとバージョンを合わせておかないとセッション開始時にエラーになります - deviceName - avd の名称と合わせる必要はないようですが、無いとエラーになりました - app - apkのパス。Android アプリはリリース版もエミュレータで起動できるのが嬉しいです。 - appPackage - パッケージ名 - appActivity - メインクラスの名称

{
  "platformName": "Android",
  "platformVersion": "7.0",
  "deviceName": "Nexus 5",
  "app": "/Users/muneakiosawa/MyAndroidApp/app/build/outputs/apk/app-release.apk",
  "appPackage": "com.MyApp",
  "appActivity": ".MainClass"
}

Android アプリ向けにappiumでテストスクリプトを書かないといけない方は appium-desktop を是非とも使って見ましょう。

fastlane のプラグインを使ってみよう

iOS アプリの継続的インテグレーションで有名な fastlane ですが、今日はそのプラグイン機能について紹介します。

fastlane plug-in とは

fastlane はかなり多機能ですが、標準のコマンドでサポートされていない機能をプラグインを使用して機能を拡張できます。以下は公式のサイトです。

セットアップ方法

Fastfile の隣に Pluginfile を作成し、 そこに必要なプラグインを定義します。以下の例は Pluginfile の内容で fastlane-plugin-update_project_codesigning を追加しています

# Autogenerated by fastlane
#
# Ensure this file is checked in to source control!

gem 'fastlane-plugin-update_project_codesigning'

以下のコマンドを実行し、プラグインをセットアップします

fastlane install_plugins

このコマンドを実行すれば plugin の環境が構築され、Fastfileの中などから plugin を使用することができるようになります。

Plug in の種類

使用可能な plug in は以下のコマンドで一覧することができます。

fastlane search_plugins

fastlane の通常コマンドでできないことがある場合は、Plug in をチェックしてみてはいかがでしょう?

appium-desktop の紹介

はじめに

Xcode 8 になり、UI Automation が廃止された関係で、アプリ版の appium (Ver.15.x) が使えなくなっていました。自動テスト自体はコマンドライン版の appium Ver.16 を使用すれば良いのですが、自動テストのスクリプトを書く際に UI パーツの ID などを特定するのに appium inspector が使えなくて困るという人は多いはず。

本家のトラブルシューティングには appium server を Ver.16 で起動し、appium inspector 使えば回避できるよ〜と記載してありますが、先日 appium-desktop なるものがリリースされました。

github.com

セットアップ方法

dmg 形式で配布されているので、通常通りインストールするだけです。

Release v1.0.0 · appium/appium-desktop · GitHub

appium-desktop でできること

  • appium server の起動
  • appium inspector

appium server の起動はコマンドライン版とほとんど差はなく、Host の IP Address と Port を指定してサーバーを起動します。

そして本命の appium inspector ですが、従来の機能はほとんど踏襲するだけでなく、使いやすくなっています。

appium inspector の起動方法

appium.app を起動すると、起動画面が表示されます。

f:id:munacky:20170413185314p:plain

「Start Server v.x.x」ボタンを選択すると appium server が起動します。

f:id:munacky:20170413185533p:plain

右上にある「Start New Session」を選択すると、Session の起動画面が表示されます

f:id:munacky:20170413185720p:plain

Session の起動画面で Desired Capabilities を入力して、「Start Session」 ボタンを選択して Session を開始します。automationName:‘XCUITest’ を設定しないと、従来の UI Automation を起動しようとしてエラーになります。

以下の通り、appium inspector が起動しました。

f:id:munacky:20170413185956p:plain

最後に

セットアップから appium inspector 起動までの手順を紹介させていただきました。Xcode8 で appium inspector が使えなくて困っていた方は ぜひ、導入してみてください。便利ですよ。

Circle CI で iOS アプリと Android アプリのビルド番号を更新する

Circle CI のビルド番号を AndroidiOS のアプリのビルド番号に反映させる方法を紹介します。

Circle CI のビルド番号とは

Circle CI ではビルドごとに一意の値が決まるようにビルド番号を環境変数で用意しています。

CIRCLE_BUILD_NUM

この環境変数は Circle CI 側でナンバリングされます。

AndroidiOS の共通ルール

iOS アプリも Android アプリもアプリケーションのバージョンとビルドを特定するためのプロパティを持ちます。自分の今まで手がけているプロジェクトではバージョン番号は手動で更新、ビルド番号は自動で更新するようにシステムを構築することが多かったです。

Android のバージョン番号

Android のバージョン番号はアプリケーションの build.gradle の中にある defaultConfig に記載します。 以下の例では versionCode をビルド番号として、versionNameにバージョン番号(この例では 1.0.0)を記載しています。 versionCode には環境変数 CIRCLE_BUILD_NUM があれば、その番号をビルド番号にして、なければ 1 を使用します。 なので、Circle CI 上ではなく手元でビルドすると常に1になります。

android {
    compileSdkVersion 2X
    buildToolsVersion "2X.X.X"

    defaultConfig {
        applicationId "com.myApplication"
        minSdkVersion XX
        targetSdkVersion XX
        versionCode System.getenv("CIRCLE_BUILD_NUM") ? System.getenv("CIRCLE_BUILD_NUM").toInteger() : 1
        versionName "1.0.0"

    }

iOS のバージョン番号

iOS のバージョン番号は info.plist に格納されています。以下の例では CFBundleShortVersionString に Version 番号を、CFBundleVersionにビルド番号が格納されています。この例ではバージョン番号は 1.0.0、ビルド番号は1です。

 <key>CFBundleShortVersionString</key>
    <string>1.0.0</string>
    <key>CFBundleVersion</key>
    <string>1</string>

plist ファイルを直接更新することもできますが、XMLの値更新などをゼロからテンプレート処理をしようしてやるのは結構大変なので、自分は fastlane の機能を使用してビルド番号を書き換えています。 以下のように fastlane でビルド番号を更新する lane を作成してビルドの前に呼び出します。

Fastfileの抜粋です。fastlane のアクション increment_build_number に対して番号を設定することによって、ビルド番号を指定できます。

  desc 'Set build number to CIRCLE_BUILD_NUM'
  lane :set_build_num do
    buildNum = ENV['CIRCLE_BUILD_NUM']
    if buildNum == nil then
      buildNum = "1"
    end
    increment_build_number build_number: buildNum
  end

この lane を呼び出すことによってinfo.plistファイルが更新されます。

更新したビルド番号を Git に反映すべきか否か

現状は更新したビルド番号を Git には反映させていないが、ポリシーによっては反映させることも必要になります。ただ、その場合は android のbuild.gradleに環境変数を埋め込むのではなく、テンプレート処理などを行って、ファイルを書き換える処理が必要になります。

また、CIで Git を更新する場合はこの更新によってCIが起動しないように、Gitのコミット時にコメントの頭に [ci skip] をつけるなどしないと、永遠に CI が回り続けるので注意しましょう。

もっと、良いやり方があれば、指摘していただけると幸いです。

iOSとAndroidの同時開発で Circle CI を使用する

はじめに

iOSAndroidのクロス開発を行なっているのですが、Circle CIを使用してインテグレーションすることになったので、概要をまとめてみました。

Circle CI の仮想環境は Mac OS を使用する

Circle CI では仮想環境をLinuxMac OS から選ぶことができます。(Mac OSは有料プランでしか選べませんが…)

iOSAndroid のクロス開発を行う場合は Circle CI は Mac OS仮想マシンを使う必要があります。これは、Mac OS仮想マシンでなければ iOS 版をビルドできないためです。

Circle CI で iOS 版と Android 版をビルドするときの大まかな流れ

1つのリポジトリiOS版とAndroid版を開発しているケースを想定しています。

Circle CI は関連づけられているリポジトリの更新を感知してインテグレーションを開始します。そのため、基本的には1つのインテグレーションのサイクルでiOS版とAndroid版をそれぞれビルドして、まとめてデプロイすることになります。

  • iOS のビルド環境を構築する
  • Android のビルド環境を構築する
  • iOS 版をビルドする
  • Android 版をビルドする
  • デプロイ

iOS のビルド環境を構築する

Circle CI の Mac OS の仮想環境には既に必要な XCode 等はインストールされているので、使用する XCode のバージョンを指定する。circle.yml の machine に xcode のバージョンを記載します。

machine:
  xcode:
    version: 8.2

ビルドツールとしてfastlaneを使用するのであれば、dependenciesでセットアップしておきます。また、2017年4月時点では Cocoa Pods や npm モジュールは Podfile や package.json などの設定ファイルの存在をチェックして自動でやってくれますが、念のため明示的にセットアップするように circle.yml に記載するほうが好きです。

dependencies:
  override:
    - gem install fastlane
    - pod install
    - npm install

Android のビルド環境を構築する

Circle CI の用意してくれる Mac OS の仮想環境には Android 向けの開発環境は入っていないため、自力で構築する必要があります。 おおよその場合、android-sdk と関連ライブラリをセットアップします。

android-sdk はつい最近まで、brewでインストールできたましたが、brew caskに移動したので、cask からインストールします。また、関連ライブラリは従来は android コマンドで実行していたが、つい最近廃止になり、sdkmanagerコマンドでセットアップすることになっています。

dependencies:
  pre:
    - brew install Caskroom/cask/android-sdk
    - sdkmanager "platforms;android-23" "build-tools;23.0.1"

sdkmanagerについては今度細かく書きたい。

自動テストを行う

自動テスト用のビルドを行い、自動テストを実施します。iOS版とAndroid版を両方ビルドして検証するべきですが、時間がかかるのが悩ましいところです。 iOS版とAndroid版のビルドについてはざっくりと紹介します。

iOS 版をビルドする

自分はiOS 版のビルドには fastlane を使っていますが、 XCodeコマンドラインツールを直接実行する方法もあります。fastlane はビルドから署名までいろいろと便利機能が充実しているので便利です。 更新されたブランチを特定してfastlaneのオプションを切り替えることによって署名を検証向けと製品向けを切り替えることができます。

Android 版をビルドする

Android 版のビルドは標準の Gradle を使用してビルドします。

デプロイ

変更されたブランチを特定してデプロイ先を変更することができます。Masterブランチの場合は App Store、Develop ブランチの場合は検証用のWebサーバーなどに配置します。 DeployGate などのツールを使用すれば、お金はかかりますが労力は軽減されそうです。

最後に

Circle CI を使用して iOS 版と Android 版を一緒にビルドする方法を中心にまとめてみました。Mac OS 上での コマンドラインベースのAndroidの環境構築を行なっている人が少ないので、参考になれば幸いです。

ブログ開設にあたって

長年付き合いのある知人から「会社に引きこもってばかりいるのはイクナイ、何かアウトプットするのが良い(意訳)」とアドバイスをもらい、確かに何かアウトプットしないとバランスが良くないよなぁということと、自分が普段の開発で得られた知見を整理してアウトプットすることによって、さらなる理解を深めたいという欲もあって、遅まきながらブログを初めてみることにしました。

ブログのトピックは以下のようなものを想定しています

  • 日頃の開発で得られた知識や経験
  • 書籍の感想(主に技術書)
  • 普段使いしているガジェットの使用レビュー

自分が楽しみつつ、自分の知識や経験を再構築したものを世の中に還元できると嬉しいなぁ。

なるべく、文字ばっかりにしないように心がけたいです。