ScalaでAndroid 2012年冬

このエントリはAndroid Advent Calendarの6日目裏です。今日の表は@ngsw_taroさんです。

さて、AndroidといえばScalaやKotlin、Haxeなど*1で書くことが多いと思いますが、今回はその中でも割とメジャーなScalaでのやり方についてまとめてみます。
Scalaで書くための手法はいくつかありますが、今回は現在最も主流である(と思われる) sbt android plugin (https://github.com/jberkel/android-plugin) を使った方法について書きます。
開発の流れとしてはターミナルでアプリケーションの作成とテスト、ビルドをして、コードはIDEとかで書く感じになります。

環境準備

何はともあれ開発環境を整える。入れなければならないのは以下の通り。

Scala本体とandroid sdkはいいとして、sbtはMavenっぽいScalaのビルドツール、giter8はプロジェクトのひな形を作るためのツールです。
いずれもTypesafe — Stack: Downloadに沿ってインストールしておきます。Macなら全てhomebrewで入るのでぬるげーです。ちなみに今回使用したバージョンは以下になります。

λ ~/sandbox/ → scala -version
Scala code runner version 2.9.2 -- Copyright 2002-2011, LAMP/EPFL
λ ~/sandbox/ → sbt sbt-version
[info] Loading global plugins from /Users/takashabe/.sbt/plugins
[info] Set current project to default-171b7b (in build file:/Users/takashabe/sandbox/)
[info] 0.12.1
λ ~/sandbox/ → g8

giter8 0.4.5

android sdkは普通にインストールしておき、pathを通して環境変数を作っておきます。r21を使っています。

λ ~/ → cat .zshrc_custom 
## いろいろ略

# ANDROID-SDK
export ANDROID_SDK_HOME=/Applications/android-sdk-macosx/
export PATH=/Applications/android-sdk-macosx/platform-tools:/Applications/android-sdk-macosx/tools:$PATH

プロジェクトを作る

何はともあれgiter8でひな形を作っておきます。注意点としてはProguardをtrueにしないとコンパイルに失敗します。

λ ~/sandbox/ → g8 jberkel/android-app

Template for Android apps in Scala 

package [my.android.project]: com.takashabe.sample
name [My Android Project]: sample
main_activity [MainActivity]: 
scala_version [2.9.2]: 
api_level [10]: 
useProguard [true]: 
scalatest_version [1.8]: 

Applied jberkel/android-app.g8 in sample

λ ~/sandbox/ → cd sample 
λ ~/sandbox/sample/ → ls
project src     tests

この状態で一度動かしてみます。テストとかビルドとかは全てsbt経由で行います。
android:package-debugコマンドでコンパイルして、android:start-deviceでapkを流し込むっぽいことをやってます。
なお、エミュレータで動かす場合はandroid:start-deviceをandroid:start-emulatorとすれば良いだけです。

λ ~/sandbox/sample/ → sbt
[info] Loading global plugins from /Users/takashabe/.sbt/plugins
[info] Loading project definition from /Users/takashabe/sandbox/sample/project
[info] Updating {file:/Users/takashabe/sandbox/sample/project/}default-883c40...
[info] Resolving org.scala-sbt#precompiled-2_10_0-m7;0.12.1 ...
[info] Done updating.
[info] Compiling 1 Scala source to /Users/takashabe/sandbox/sample/project/target/scala-2.9.2/sbt-0.12/classes...
[info] Set current project to sample (in build file:/Users/takashabe/sandbox/sample/)
> ;android:package-debug;android:start-device

## 略

[info] Dexing /Users/takashabe/sandbox/sample/target/classes.dex
[info] Packaging /Users/takashabe/sandbox/sample/target/sample-0.1.apk
[success] Total time: 19 s, completed Dec 5, 2012 2:15:11 AM
[info] Wrote /Users/takashabe/sandbox/sample/target/scala-2.9.2/src_managed/main/scala/com/takashabe/sample/TR.scala
ProGuard, version 4.6
ProGuard is released under the GNU General Public License. You therefore
must ensure that programs that link to it (scala, ...)
carry the GNU General Public License as well. Alternatively, you can
apply for an exception with the author of ProGuard.
The output seems up to date
[info] Packaging /Users/takashabe/sandbox/sample/target/sample-0.1.apk
[info] 	pkg: /data/local/tmp/sample-0.1.apk
[info] Success
[info] 3127 KB/s (177013 bytes in 0.055s)
[info] Starting: Intent { act=android.intent.action.MAIN cmp=com.takashabe.sample/.MainActivity }
[success] Total time: 3 s, completed Dec 5, 2012 2:15:14 AM
> 

Hello, world!
f:id:takashabe:20121205023134p:plain
この時点でビルドに失敗する場合はproject/plugin.sbtとかBuild.scalaで指定されているpluginのバージョンが間違っている可能性があります。っていうか以前はよくありました。

IDEとの連携

ビルド出来ることは分かったので、次はIDE上にプロジェクトをimportする方法について見ていきます。
sbtでは各種IDE用の設定ファイルを生成するためのPluginが存在するので、まずはそのPluginを使うようにします。
以下のようにplugin.sbtに下4行を追加すればいいだけですが、空行を開ける必要があるので注意です。1.2.0-SNAPSHOTの部分は適宜最新バージョンを指定してください。*2
ちなみにプロジェクトごとに毎回書くのがだるい場合は~/.sbt/plugins/build.sbtあたりに書いておけばプロジェクト全体に勝手に適用されます。

diff --git a/project/plugins.sbt b/project/plugins.sbt
index e3163f8..a7580b7 100644
--- a/project/plugins.sbt
+++ b/project/plugins.sbt
@@ -1,3 +1,7 @@
 resolvers += Resolver.url("scalasbt releases", new URL("http://scalasbt.artifactoryonline.com/scalasbt/sbt-plugin-releases"))(Resolver.ivyStylePatterns)

 addSbtPlugin("org.scala-sbt" % "sbt-android-plugin" % "0.6.2")
+
+resolvers += "Sonatype snapshots" at "http://oss.sonatype.org/content/repositories/snapshots/"
+
+addSbtPlugin("com.github.mpeltonen" % "sbt-idea" % "1.2.0-SNAPSHOT")

次にsbtを起動した時にPluginのインストールが始まるので、以下のコマンドでIDE用のファイルが生成されます。

> gen-idea

## 色々生成している

> exit
λ ~/sandbox/sample/ → λ git master* → l
total 0
drwxr-xr-x   9 takashabe  staff  306 Dec  6 20:12 .
drwxr-xr-x   3 takashabe  staff  102 Dec  5 02:07 ..
drwxr-xr-x  13 takashabe  staff  442 Dec  6 20:16 .git
drwxr-xr-x  11 takashabe  staff  374 Dec  6 20:12 .idea
drwxr-xr-x   5 takashabe  staff  170 Dec  6 20:12 .idea_modules
drwxr-xr-x   6 takashabe  staff  204 Dec  6 19:58 project
drwxr-xr-x   4 takashabe  staff  136 Dec  5 02:07 src
drwxr-xr-x  12 takashabe  staff  408 Dec  6 20:12 target
drwxr-xr-x   4 takashabe  staff  136 Dec  6 20:12 tests

あとはIDEA上でプロジェクトをopenすればOKです。Scala Pluginはインストールしておく必要があります。
syntax highlightされなかったりpathが見つからないとか言われた時はProject StructureでJDK, Android jar, Scalaのpathを編集すれば何とかなるはずです。。。この記事書いてる時点でクリーンな環境が無かったのであばばば
とりあえず今日発表されたばかりのIDEA 12でも動作してます。

f:id:takashabe:20121206204737p:plain

継続的にビルドする

sbtではファイルを監視して変更があれば任意のコマンドを実行する機能があります。先頭に ~ つけるだけです。ちなみにセミコロンはコマンドの区切りです。

> ~;android:package-debug;android:start-device

実行するコマンドは何でも良いので ~test とかやれば自動的にテストを回せて素敵です。
ただし、project配下のファイルの変更は監視しないのでplugin.sbtとかに設定を追加した場合は手動でupdate/reloadする必要があります。

Google Playにデプロイする

ではこのsampleアプリもGoolge Playでヒットするアプリに育ったのでデプロイしてみようと思います。
証明書を作る工程は通常と同じです。*3 今回はalias_nameで証明書を作っているものと仮定して進めます。
証明書を作ったらproject/Build.scalaのkey値を証明書に合わせて変更します。

diff --git a/project/Build.scala b/project/Build.scala
index 13dc305..423ec0c 100644
--- a/project/Build.scala
+++ b/project/Build.scala
@@ -23,7 +23,7 @@ object General {
     proguardSettings ++
     AndroidManifestGenerator.settings ++
     AndroidMarketPublish.settings ++ Seq (
-      keyalias in Android := "change-me",
+      keyalias in Android := "alias_name",
       libraryDependencies += "org.scalatest" %% "scalatest" % "1.8" % "test"
     )
 }

次にsbt上で署名してrelease用のapkを生成します。
target/sample-0.1-market.apkがrelease用のapkです。

> ;android:package-release;android:prepare-market

## 略

Enter password for keystore/alias_name: **********
[info] Signed /Users/takashabe/sandbox/sample/target/sample-0.1.apk
[info] Aligned /Users/takashabe/sandbox/sample/target/sample-0.1-market.apk
[success] Ready for publication: 
[success] /Users/takashabe/sandbox/sample/target/sample-0.1-market.apk
[success] Total time: 6 s, completed Dec 6, 2012 9:24:50 PM

ただ、この状態でGoogle Playにデプロイしようとするとエラー内容もなく怒られちゃいます。
f:id:takashabe:20121206221318j:plain

これは以前どハマりしたのですが、どうやらデフォルトのiconのままだとダメっぽい。なので適当な画像を用意してmanifestを書き換えます。
画像を置く場所はいつもどおりres以下に置きます。

λ ~/sandbox/sample/src/main/res/ → λ git master* → l
total 0
drwxr-xr-x    8 takashabe  staff   272 Dec  6 21:33 .
drwxr-xr-x    6 takashabe  staff   204 Dec  6 21:35 ..
drwxr-xr-x@ 145 takashabe  staff  4930 Dec  6 21:33 drawable-hdpi
drwxr-xr-x    3 takashabe  staff   102 Dec  6 21:33 drawable-ldpi
drwxr-xr-x    3 takashabe  staff   102 Dec  6 21:33 drawable-mdpi
drwxr-xr-x    3 takashabe  staff   102 Dec  6 21:33 drawable-xhdpi
drwxr-xr-x    3 takashabe  staff   102 Dec  5 02:07 layout
drwxr-xr-x    3 takashabe  staff   102 Dec  5 02:07 values

AndroidManifest.xmlも上記の画像を読み込むように変更。

diff --git a/src/main/AndroidManifest.xml b/src/main/AndroidManifest.xml
index 62f45c8..f7f1b26 100644
--- a/src/main/AndroidManifest.xml
+++ b/src/main/AndroidManifest.xml
@@ -2,7 +2,7 @@
     package="com.takashabe.sample">

     <application
-        android:icon="@drawable/android:star_big_on"
+        android:icon="@drawable/ic_launcher"
         android:label="@string/app_name"
         android:debuggable="true">

もう一度release用のapkを作成して、再度デプロイ!
f:id:takashabe:20121206221314j:plain

そういえばバージョン0.1のままでしたので怒りを抑えて整数に直します。
ここで普通ならばAndroidManifest.xmlを直接編集しますが、sbtプロジェクトの場合はproject/Build.scalaのkeyを編集します。*4
でもさっきiconを変えるときにmanifest見たけどバージョンかかれてなかったぞ・・・?とか思われるかもしれませんが、src/main/AndroidManifest.xmlは最終的なmanifestではなくてコンパイル時にsbtがパースして別のmanifestを生成します。*5

diff --git a/project/Build.scala b/project/Build.scala
index 423ec0c..2bfbd80 100644
--- a/project/Build.scala
+++ b/project/Build.scala
@@ -6,8 +6,8 @@ import AndroidKeys._
 object General {
   val settings = Defaults.defaultSettings ++ Seq (
     name := "sample",
-    version := "0.1",
-    versionCode := 0,
+    version := "1.0",
+    versionCode := 1,
     scalaVersion := "2.9.2",
     platformName in Android := "android-10"
   )

これでもう一度apkを生成してデプロイします。
f:id:takashabe:20121206221258j:plain

やりました。メガヒット間違いなしですね。*6


ほんとはテストとかjenkinsとかも書きたかったのですが長くなってきたのと体調がひどい感じなのでここで終わります。テストとかはまた今後書くかも。
明日のAdvent Calendarは表 @chun_ryoさん、裏 @Arigata3さんです。たのしみ!

*1:最近はJavaで書くことも多いようだ

*2:https://github.com/mpeltonen/sbt-idea

*3:http://techbooster.org/android/environment/1445/

*4:sbtでのバージョンとapkのバージョンを合わせたかったのだと思います。たぶん。

*5:target/scala-x.x.x/resource_managed/main/AndroidManifest.xml

*6:大人の事情により消しました。

Androidテスト勉強会 9月8日(土) #atest_hack に行ってきた

Androidテスト勉強会 9月8日(土) #atest_hack on Zusaar
に行って来たのでその時のメモなど。

全体的にAndroidだからこうテスト書こう、よりもテストは何のためにやるのか、テストの種類とは、みたいな一般化したお話が多かった印象。
あとGroovy使いが多かった。Gradle興味あるので触ってみようかなぁ
スライド内でも紹介されていたけど、Androidのテストについては
連載インデックス「Androidアプリ開発テスト入門」 - @IT
こちらを見るといいと思う。

以下会場で取ったメモ。後半あんまり取れてない…。

ソフトウェアテストな人同士で合わせておきたい5つの概念

@snskさん(しんすくさん(Androidテスト部))

品質とは
  品質それ単体では何もいってないよね
  品質モデル
    PQM Lite
      機能実装度合い
      セキュリティ、プライバシー
      信頼性
      覚えやすさと気持ちよさ
      時間と資源のパフォーマンス
      変更のしやすさ ←これがデベロッパテストで担保すべき場所
      スケーラビリティ

テスト技術とプロセス品質技術
  テスト技術→成果物を知るための技術
  プロセス品質技術→プロセス自体の成熟度を知る技術
    プロセス自体です。設計レビューの時間とか

テストレベル
  Vモデル
    要求      : 受け入れテスト
    基本設計  : シナリオテスト
    詳細設計  : 結合テスト
    実装      : コンポーネントテスト
  NativeDriverいちおし

自動化ツール
  受け入れ、シナリオテストの話!
    自動化で削減出来るもの
      →実行工数のみ
    初期の投資コストは手動より高くつくよね
    メンテコストは手動とほぼ同様だよね
    コスト的に手動<自動となるのは、3回以上実行するもの
  コンポーネントテストは自動化普通だよね?

誰がためのテストか
  仕事として?
  顧客のため?
  自分(将来)のため?

  将来作っていくことを考える場合
    変更のしやすさが超重要!!
      →分厚いドキュメントをかく()
      →Unittestをかく

テストは知る技術 →技術がいる
既知のものを調べるのはチェック

Sue445 Style TDD

@sue445 さん (AZusaar!の中の人。TDDクラスタ(他多数)代表)

Sue445 Style TDD #atest_hack

Junit実践入門にAndroidのテストもかかれてるよ!

テストの種類
  QA testing
    セキュリティ、バグとか
  Developer testing
    開発促進(TDD)はここ
  customer testing
    使いやすさとか? //todo あとでみる

TDDは設計だよ!

1.テストファースト
2.Redにする
3.実装する
4.Greenにする
5.テストが動くままでリファクタリング
  黄金の回転!

Clean Codeの Martinいわく
TDD三原則
  テストファースト
  失敗するテストを書くまでは次のテストは書かない
  失敗するテストがある限り次のプロダクトコードは書かない

テストファーストの重要性
  テストを書くには何が必要なのか
    入力
    出力
    クラス、メソッドの責務。パターンわけなど
  →これって設計だよね
    作りたいものを明確にしてからじゃないといけない
    あやふやな仕様を明確にする→テストファーストによって
    赤→緑になるときもちいいよね!

TDDのための一般的な理由
  和田さんのスライドをみましょう
  健康のため
  素早くフィードバックをえる

  テストコードのリファクタリングは?
    同じテストコードが複数出てきたらし始める感じ

ソフトウェアテスト入門

@sassy_watson さん (Androidテスト部)

テスト初心者Androiderのためのソフトウェアテスト入門

テーマ
  テストの種類について
  テスト技法について

何をテストしたいかを把握するためのテストの種類を明確にする
V字モデルに基づいて
  要件定義
    やりたいことを明確にする
  基本設計
    画面などの基本的な設計
  詳細設計
    実装のための設計(シーケンス図とかクラス図とか)
  実装
    実装

  ざっくり分類
    プログラムで確認するテスト
      ・単体テスト
        JUnitとかで確認するよ
        細かい単位でテスト
          直流の電球回路で1個ずつテストしたらつなげてもつくことがわかるよね
        他のモジュールに依存するユニットテストをするには
          他モジュールが何を返すのかわからん→Mockを使いましょう!
          android.test.mockパッケージのクラスを使ってテストできる
            overrideしないと基本的にExceptionをはく
          android-mockというフレームワークもある

      ・結合テスト
        androidだとユニットテスト結合テストの境界が曖昧
          他のActivityに依存したりが多いから
          Androidだとユニットテストしづらいから結合テストでがんばるのもアリ

    実機で確認するテスト
      システムテスト
        仕様通りに動くかどうかのテスト
        仕様書からテストケースを抽出する必要があり
        機能だけでなくて、Performance、Securityとかの非機能要件も考慮する必要があるよ
      受け入れテスト
        主にお客様が自分たちの要求を満たしているかを確認するテスト

テスト技法について
テストを効率的にするにはどうすればいいのか
  →テスト技法を用いてテストしよう!

よりよりテストとは
  多くのバグを発見
  少ない時間で発見

代表的なもの
  同値分割
    類似値をグルーピングしてそれらが同じ値がかえるか
      →1とか3とか5とかの値を入れても同じ値が返ってくる
      →グループの代表値のみ入れてテストの数を減らす
  境界値分析
    同値分割(グルーピング)した境界値に注目
    境界値はバグが出やすい
      255文字入力出来るEditTextの場合:
      →0とか−1とか1とか255とか256とか
  デシジョンテーブルテスト
    入力と出力の関係表を元にしたテスト

  他のテスト技法
    状態遷移テスト
    原因結果テストなど…

  テスト技法ポジションマップ
    テスト技法について、これはどのへんに効果的だよとかの図。よさそう

  マインドマップからはじめるソフトウェアテスト
    上層の話になるかも
    テスト設計の勉強に
  ソフトウェアテスト技法ドリル
    テスト技法をドリル形式で
    テスト設計の勉強に
  Androidならテスト部の記事を!

テストはあくまでもバグを出すための手段であり、
テスト=目的となってはいけない
品質/コスト/納期とかのバランスを考えよう

GroovyなAndroidテスト

@alterakey さん (埼玉支部・デ部 「炎のAndroid開発道場」の著者の一人 android-runner開発者)

GroovyなAndroidテスト #atest_hack

標準のAndroid testing frameworkは遅い
そこでGroovy!
  privateメソッド呼べるし

Androidだと簡単に使えない
  Discobotとか実績あり?

  JVMのテストならOK!

JVMでテストとは
  Robolectric
  AndroidアプリをJVMでテストするためのフレームワーク

  Android ant runner
    antのみ現在は
    EclipseとかIDEとかは・・・
    Unix限定

そもそもテストとは
  テストとは設計手段である

Robolectricはパラメタライズドテストが使えない
Robolectricを使わなければパラメタライズドテストできるけど

//詳しくはスライドを見る。内容濃い

実務に近いテストコードを書いてみる

@kimukou2628 さん (Androidテスト部)

Try_to_writecode_practicaltest #atest_hack

テストってググり駆動できないよね

昔はWebページの広告枠をかう→いまはアプリの枠を買う
  Mediationが注目

端末ごとのハマりポイントなど
  //スライドにまとまっている。いい内容。あとGalaxy Nexus安定

iPhoneでのunit test

@mike_neck さん (Androidテスト部)

i-Phone unit-test

obj-cでどうやってテストをしながらアプリを実装していくか
アプリが持つ要素を洗い出す

テストをする前に何がテスト出来るか、をモデルの取り得る値を洗い出す

プロジェクトを作るときはinclude unit testにチェックを入れること!
  →入れないとプロジェクトのxmlをゴリゴリしないとだめ。めんどい

Twitter4jとテスト (タイトル変更された模様)

@yusuke さん (Twitter4J開発者。「Twitter APIポケットリファレンス」著者)

Twitter4Jとテスト

Twitte4jの開発、テスト環境について
環境
  IDEA/maven/jenkins/jira/github/sonatype

Android環境の自動テスト
  Android Emulator Plugin

Twitter4jとテスト
  まずAPIとの疎通確認
  アナウンス無しに仕様変更になる場合がある
    →テストが必要(CI)

  Twitte4jを使うアプリケーションでは
    Twitter4jがやってくれることはテストしないよ
      パラメータ、レスポンスの型
      APIコール失敗時のリトライ
    ビジネスロジックは必要
      正常系はあまり問題ない
      異常系
        ↓が同じ状況を作り出すのが面倒
        twitterが落ちてるとか
        レートリミットに到達した場合のテスト

  メトリクス分析から見るソフトウェア品質の本
    データ指向のソフトウェア品質マネジメント

  テストは動的な品質向上・担保の手段
  静的な手段としては
    コンパイラ
    静的解析
    コードメトリクス
  外部APIとかと接続する箇所は仕様に頼り過ぎない
    →Twitter API1.1で廃止予定のメソッドが今は呼べたり、OAuth無しでいけたり
    →ドキュメントが追いついていないとか

テストケースの失敗について
  たまたま失敗しているのか→そのままでいいよね
  継続的に失敗しているのか→対策しないとやばい
    jenkinsでテストしている場合はテストごとのageで何回連続でテスト失敗しているかが分かる

  jenkinsのテスト結果を待って次の作業は効率悪いので、テスト中に別のことをやり始める

  異常系テストはMockを使う

logcatをコンソールで色分けしたりフィルタしたりする

コンソールでlogcatを見るときに色分けしたり開発中のアプリだけフィルタしたりする方法

f:id:takashabe:20120830010900j:plain

  • 色付け

いい感じに色付けしてくれるスクリプトがあるのでそれを使いましょう。
Jeff Sharkey » Modifying the Android logcat stream for full-color debugging

使い方はこんな感じです。logcat -v でのフォーマット指定は対応していないみたいです。

$ adb logcat | coloredlogcat.py 


  • フィルタ

locat単体ではpidや特定文字列でフィルタ出来ないのでawk使ったりするのがいいんじゃないかなと思います。
例えばアプリ名sampleとpidの192でフィルタして色分けする場合は以下になります。

$ adb logcat | awk '/\(.*192)\/ || /sample/' | coloredlogcat.py

この他、logcatのオプションでtagとpriorityでフィルタもできます。
タグhogeだけ表示する場合はタグ指定して、残りは'*:s'で落とす感じになります。

$ adb logcat 'hoge:v' '*:s'


これでログだけ見たい時にIDE立ち上げなくてもいいので便利。

Android + ScalaでProGuardの設定をする

Androidでtwitter4jなどの外部ライブラリを使うと、ProGuardがご丁寧にクラスを除外してくれてClassNotFoundExceptionなどが出たりして困ります。
その場合はProGuardにオプションを与える必要があります。

sbt android pluginではbuild.scalaあたりに以下のようにproguardOptionを追加してやればOKです。


設定したオプションはsbtの以下コマンドで確認出来ます。

> android:proguard-option
[info] -dontnote **
[info] -keep class twitter4j.** {*;}


ちなみにproguardOptionはパラメータ毎に改行で区切る必要があるので複数行リテラル使っていますが、\nを入れてやれば普通の文字列でも大丈夫です。

全然関係ないけどgist記法簡単ですげー便利だね。

第2回 Androidテスト祭りにいってきた。 #atecfes2

第2回 Androidテスト祭り : ATND
に行ってきたのでメモ書きや感想などを書いておきます。


まとめ記事、Togetterはこちら
第2回 Androidテスト祭り に参加してきた #atecfes2 - Shinya’s Daily Report
2012/04/28 第2回 Androidテスト祭り #atecfes2 - Togetter

招待講演「Androidのセキュリティと品質保証の問題について」

  • 谷口 岳 様 (タオソフトウェア株式会社 代表取締役)

Androidセキュリティ本のタオソフトウェアさんのお話。

Android Security  安全なアプリケーションを作成するために

Android Security  安全なアプリケーションを作成するために


資料は以下URLの2012/4/27 第2回テスト祭りからダウンロード可能。
Android Security - 安全なアプリケーションを作成するために

  • アプリ内の著作権データについて
    • データはすべて簡単に抜き取れる
      • PCと接続してAPK抽出
        • APKは実はzipファイルなので、拡張子を変えると構成ファイルを取り出せる
      • Android上でアプリによるリソース吸出し
        • 参考アプリ: tPackageExplorer
        • アプリケーションのリソース情報を認識可能
    • ソースコード解析について
      • Javaなので解析簡単、ツールも出まわってるし
        • アプリ内のPasswordとかを保存してるとすぐに抜き取られる
        • root化必要なし
        • Proguardで難読化(ただの時間稼ぎだけど)
    • まとめ
      • データの抜き取りは簡単に出来る
        • アプリ内にセキュアなファイルはおいておかない
        • サーバからデータを取得など
  • 利用者の個人データなど
    • 原因→わざと流出させることはない。バグやAndroidに対する知識不足が大きい
    • Androidのセキュリティモデルを理解する必要がある
  • Androidのセキュリティ構造
    • 署名
      • 自己署名で、アプリが同一作者のものかどうかの判断に使用
    • ファイルパーミッション
      • Linuxのそれと同じ
      • ファイルの場所によって必要な権限が異なる
      • アプリケーションデータディレクトリのものはroot取らない限り見れない
      • SDカード内のデータは権限なしで読み取り可能
    • Intent使用時の注意
      • ActivityManagerログにActivityに送られたインテントの内容が出てくる
        • ID, パスワードなど書いていた場合は出てくるので注意
        • Android 2.3で隠蔽されるようになった
      • インテントのデータは他アプリで取得可能なもの
        • 他の方法でデータは渡そう
        • インテントデータの暗号化(ただし、あまり良くない方法)

ユーザとベンダで生討論!みんなでつくる「受入れテストガイドライン」

  • ユーザサイド : 株式会社電通プラットフォームビジネス局開発部 様
  • ベンダサイド : 生路 茂太 松木 晋祐(Androidテスト部)
  • こういう勉強会ってユーザサイドの話があまり出てこないよね
    • 無茶をいってユーザサイドの方々に来てもらいました
  • エンジニアとのパートナーシップ構築の一例
    • カヤックブログ
    • ブログがあると技術力やアプリの動作イメージなどが分かりやすい→依頼しやすい
  • アプリの魅力性について
    • こんな感じのが欲しいんだけど→言語化しづらい
    • ふわっとした部分の話って実はアプリが面白くなるかどうかでとても重要なのでは
    • 魅力性を定義
      • ゆか体操の技と点数のようなイメージ
      • 発注側と開発側での意識の齟齬も少なくなる
      • フランスで芸術が優れているのは批評家が多くいるため
        • 批評という形で芸術の魅力が定義されている

CI導入ライブ-jenkins ci server

  • Android Hacks 著者の1人
  • Jenkins のコミッター

Android Hacks ―プロが教えるテクニック & ツール

Android Hacks ―プロが教えるテクニック & ツール

  • Androidが通常アプリよりもCIが重要な理由
    • 製品のライフサイクルが早い。機種が多い
    • OSアップグレードが18ヶ月ごと→これはメーカーに課せられた義務
    • Google Playの評価は最新のものが上になる
  • JenkinsでAndroidを使うためのポイント
    • JenkinsにAndroid SDKを入れるには
      • エミュレータプラグインを入れると自動で入る
      • コマンドで入れることも可能

>| android update sdk -u

    • Antがないプロジェクトを実行するには
      • コマンドで生成できる

>| android update project

Android Bazaar and Conference 2012 Spring に行って来ました

ABC2012で参加したセッションのメモや感想をつらつらと

イベントの内容や講演資料は公式に上がってたりします
http://www.android-group.jp/conference/abc2012s/

  • 変貌するWebの世界 -- クラウドとクラウド・デバイスのインパクト(日本Androidの会 会長/丸山 不二夫)
    • 制御信号について
      • PCに比べてスマホはデータ量に対する制御信号比率が高い
      • これはFast Dormancyというバッテリ消耗を抑える仕組みがあるため
      • コネクションをすぐに解放してIdle状態を保とうとする
      • iOS4.1に比べるとAndroid2.3の方が制御信号多いんだけどAndroid 4.0でだいぶ改善された
    • Webについて
      • 現在はネイティブアプリ主流だけどWebにシフトしていくだろう
      • HTML5がキーとなる
      • 現状のHTTPのトラフィックはヘッダーのオーバヘッドが大きい
      • WebSocketはオーバヘッドを極力低減している。WebSocketつかいましょう


総務省の基調講演は途中で抜けてあまり聴いてないので割愛

  • スマートフォン時代における新たな広告収益戦略(グーグル株式会社 オンラインパートナーシップグループ/坂本達夫)
    • DLされているアプリについて
      • DLしたことある人→無料:96%, 有料:48%
      • DLしたアプリの数→無料:27.7本, 有料:4.8本
      • 有料アプリのみをターゲットにした時点で半数以上のユーザには触ってもらえない
    • 収益モデルについて
      • 有料アプリ(DL時)、アプリ内課金、広告
      • 有料、無料+広告といったアプローチもよくある
    • 広告モデルのポイント
      • 広告を入れる前提のUI設計
      • ユーザの操作を阻害しない
      • アプリ作ってから広告を後付けすると評価下がるし大変
    • Permissionについて
      • Permission自体はJavaの機能
      • Permissionだけでは同意したことにならない
    • 同意確認について
      • 個別的選択オプトイン
      • アプリ使用中に該当機能を使用するときに同意確認
    • 端末IDについて
      • 端末IDは不要、収集するべきではない
      • 端末IDは偽装可能
      • アプリ内でローカルなIDを使用して識別する
  • 「ADB(Android Debug Bridge) そのしくみから応用まで」(京都マイクロコンピュータ株式会社/小林哲之)
    • adbの構成について
      • adb client: adbコマンド
      • adbd: target device側のdaemon
      • adb server: clientとadbdを中継するproxy的な役割
    • adb serverについて
      • clientとadbd間にコネクションをはる
      • USB/TCPどちらも可能 → clientでは通信経路を考える必要なし
    • Android 4.0のadbについて
      • 4.0からはtarget device上でadb clientを使えるようになった
      • Android端末でAndroid端末のdebugとか
  • 検証、SEAndroid(Android セキュリティ部/矢倉大夢)
    • SELinuxについて
      • カーネルレイヤでパーミッションを操作
      • rootに対してもアクセス制限可能
      • 他のプロセスへの干渉を抑制出来る
      • hogehogeの脆弱性をついて他プロセスにアクセス、などに効果的
    • SEAndroidについて
      • ベースはSELinux
      • アプリによる権限昇格防止、データ漏洩の防止
      • コンテキストによってデータを保護
      • /system/bin以下はどのユーザも書き込めない
      • root取られても大丈夫、そもそも脆弱性つきにくいからroot取りづらい
      • アプリから他アプリへの干渉を避けれる
      • ただしコンテキストはきちんと設定する必要あり(デフォルトでも堅牢)

初めてABCに参加したけど技術的なセッションの他にマネタイズなどの
ビジネス系なセッションが多かったのが印象的だった。
もちろんコアなセッションもあって人気なものは5分前満席って状態も。
実は一番聴きたかったセッションが満席で入れなかったりしてアレだった。

別件があったので最後まで居れなかったのだけど知識不足を感じるにはとても満足で良かった。
もし次があればもっと技術寄りなやつとかUIなんかを中心に回ってみたい。

Android 4.0.1でScalaを動かしてみた

Android上でScalaを動かしたときのメモです。
というかぶっちゃけこちらの通りです。
https://github.com/jberkel/android-plugin

環境

Android SDKのインストール

Scalaとsbtはインストールしてる前提で進めていきます。(入ってなかったらbrew install scala sbtで入れておく)
Homebrewで簡単にインストール出来ます。ステキですね。

% brew install android-sdk

Android SDK Managerを立ち上げてSDKを入れていきます。
とりあえず全部チェック入れれば良いと思います。

% /usr/local/bin/android

~.zshrcなどにANDROID_HOMEを定義してpathも通しておきます。

export PATH=/usr/local/bin:$PATH
export ANDROID_HOME=/usr/local/Cellar/android-sdk/r16

android-pluginのインストール

% git clone git://github.com/jberkel/android-plugin.git
% cd android-plugin 
% sbt publish-local

プロジェクトの作成

giter8を使用してプロジェクトを作成します。
giter8をインストールしていない場合はHomebrewで入れておきます。

% brew install giter8

% g8 jberkel/android-app

Template for Android apps in Scala 

package [my.android.project]: com.android.hoge
name [My Android Project]: hoge
main_activity [MainActivity]: 
scala_version [2.9.1]:   # 使用するScalaのバージョンに合わせる。
api_level [10]: 14       # ターゲットのAndroidに合わせる。Android SDK Managerで確認出来る。

Applied jberkel/android-app.g8 in hoge

実機で動かしてみる。

% cd hoge 
% sbt
> android:package-debug
> android:start-device

# こんな感じに出力されて端末にhello, worldが出ていれば成功です。
3072 KB/s (168917 bytes in 0.053s)
	pkg: /data/local/tmp/hoge-0.1.apk
Success
Starting: Intent { act=android.intent.action.MAIN cmp=com.android.hoge/.MainActivity }
[success] Total time: 4 s, completed Jan 5, 2012 12:45:12 AM

エミュレータを使う場合は android:start-device の代わりに android:start-emulator を使ったりすればOKです。(エミュレータおもいのでしんどい><)
必要なものはほとんどHomebrewやgiter8で済んでしまうのでゆとりすぎますね。先人たちに感謝です。