TechBooster様の「Androidビルディングデザイン」に、弊社代表中西がAndroid Mの新しいセキュリティモデル（パーミッションモデル）の記事を寄稿しました。2015年8月25日現在、紙の書籍は完売しておりますが電子書籍版はまだ頒布されています。

電子版では、Android M Developer Preview 3、SDKバージョン23、Support Libraryバージョン23についても反映した内容に更新されていますが、その中では触れていない気をつけないといけない項目について、ここに記載します。

targetSdkVersionを23以上に上げたアプリは22以下に戻せない

Android Studioでデバッグ実行で試すとわかるのですが、targetSdkVersionを23にしたアプリをインストールし、それを22以下に変更して再度インストールしようとすると、以下の様な警告が表示されます。

Failure [INSTALL_FAILED_PERMISSION_MODEL_DOWNGRADE]

書いてあるとおり、パーミッションモデルのダウングレードを求めるようなアプリのインストールが許可されていません。この時、Android Studioは以下のようなダイアログも表示します。

ここに書いてあるのは、今インストールされているアプリをアンインストールして、それからインストールするかと聞いてきています。つまり、インストール済みのアプリの保存しているデータや設定などを維持して、targetSdkVersionを22以下に落としたアプリのインストール（アップデート）を行うことはできません。

これ、おそらくはGoogle Play Storeでも対策がなされるのではないでしょうか。

一度targetSdkVersionを23以上に上げて新しいセキュリティモデルの対象となったアプリは、targetSdkVersionを上げたことによって発生したバグがあっても、22以下に戻したアプリをアップロードすることはできなくするのではないかと。

既存アプリを運用されている場合、targetSdkVersionを23に変更するのは慎重に行うようにしましょう。

targetSdkVersion 22以下のアプリを23にした場合、パーミッションが許可状態になる

これはユーザにとっての罠ですが、Android M端末にtargetSdkVersionが22以下のアプリをインストールし、それがバージョンアップでtargetSdkVersionが23になったとしても、パーミッションが許可状態になります（Context#checkSelfPermissionがtrueを返します）。

新規にtargetSdkVersionが23のアプリをインストールした場合、最初はContext#checkSelfPermissionはfalseとなりますので、そこからActivity#requestPermissionsによって権限を取得していくという流れになります。

しかし、前述の場合は、targetSdkVersionが22のアプリをインストールした時点で、権限利用を許可したという状態が端末に記録され、それはtargetSdkVersionを23以上に上げた場合にも維持されます。

この挙動は、iOSなどで新しいOSバージョンで権限チェックが強化された場合の挙動とは異なります。iOSでは、たとえばマイク利用にユーザによる権限確認が必要となった場合、アプリの新規インストールとアップデートのいずれであってもダイアログで確認するという挙動になります。

この挙動のまま正式版となるかはわかりませんが、ユーザは気をつけておくとよいでしょう。

Android Studioは、利用するJDKを環境変数STUDIO_JDKに設定することで切り替えることができます。このことはAndroid　Tools Project Site内のMac OSX JDK Selectionで説明されています。

ただし、上記の方法では、Android Studioをいちいちコマンドラインから立ち上げないといけないため面倒です。そのため、ランチャー向けにSTUDIO_JDKの環境変数を設定しておく方が便利です。

Marvericks(10.9)では、/etc/launchd.conf に環境変数を記述しておくと、ランチャー向けにその環境変数が設定されました。しかし、Yosemiteからは/etc/launchd.confの設定は無視されます。

Yosemite以降では、/Library/LaunchAgents以下にplistファイルを作成し、その中で環境変数を設定する必要があります。適当なファイル名で以下の様なplistファイルを作成してください(たとえば com.example.android.studio.plist)。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>Label</key>
    <string>com.example.android.studio.plist</string>
    <key>ProgramArguments</key>
    <array>
      <string>/bin/launchctl</string>
      <string>setenv</string>
      <string>STUDIO_JDK</string>
      <string>/Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
  </dict>
</plist>

「com.example.android.studio.plist」は、将来的にもAndroid Studioなどが公式に作成するファイルと重ならないようにつけているだけで、ご自身の好みで名前は適当に変えてください(たとえば自分の持っているドメイン名をリバースドメインで使用するなど)。

使用するJDKのバージョンなどについても、ご自身が使用したいものを指定してください。必ずインストールされているJDKを指定してください。ここでは、執筆時点でのJava8最新のJDKを指定しています。

ファイルを作成したらOSを再起動すれば設定が反映されます。ランチャーからのAndroid Studio起動時に、STUDIO_JDKに設定したJDKが使用されるようになります。

OS再起動したくない場合、以下のようにすると追加したファイルの設定が追加反映されます。

% sudo launchctl load /Library/LaunchAgents/com.example.android.studio.plist

問題

新規作成したWearプロジェクトのビルド時に、依存ライブラリが見つからないというエラーが出て失敗します。

見つからないのは以下の2ライブラリです。

• com.google.android.gms:play-services-wearable:+
• com.google.android.support:wearable:+

原因

Wear プロジェクトの依存ライブラリがまだ配布されていません (PST 2014年6月26日 18時現在)

Android SDK Manager でSDKを最新に更新し、Android 4.4W のコンポーネントを全部インストールし、サポートライブラリとGogoleのレポジトリも最新に更新した状態でも、sdk/extras 以下に必要なライブラリファイルが配信されていないために発生しています。

解決策

待ちましょう。Android SDK Managerで配信されるコンポーネントが更新されないと解決しないため。

Google I/O 2014でGoogleの人にこの件は伝達し、さらにadt-devというAndroid開発環境に関するGoogle Groupsにも報告を送りました。

adt-dev への報告はモデレータさんがOKしないと出ないと思われるので、念のため issue tracker にも以下で登録しました。

Can’t build Android Wear application project generated by Android Studio 0.8.0

(緩和策について追記: 2014/06/27 00:16 PST)
緩和策は見つかっています。以下のURLからダウンロードしたファイルを所定のディレクトリに置くことです。

https://dl-ssl.google.com/android/repository/google_m2repository_r09.zip

(上記の説明だけで対応出来る人にしか緩和策の実行はおすすめしません。)

これは上記のissueへのコメントに示されたxmlファイルから推察されたURLであり、実際にそのファイルは存在するようです。

ただし、これは正式な方法ではありません。もしかすると同じファイル名で差し替えのファイルが提供され、その後に公式にAndroid SDK Managerからダウンロードが提供されるかもしれません。その場合、SDK Managerからダウンロードできるファイルが改善版であるにも関わらず、同じリビジョンであるためにダウンロードが行われないということが起こる可能性もあります。

リスクを勘案し、元に戻せるようにするなどの対策をした上で使用することをおすすめします。

おまけ: Android Wearについて

Google I/O 2014にて参加者に先行して端末が配布されました。

実際に半日使用してみたところ、スマートフォンを取り出して確認するという行動がかなり減り、いろいろと快適になった感じがします。

ハングアウト(Google+のチャット機能)やTwitterへの返信を、日本語の音声入力で腕時計から簡単に返すというようなことも出来て非常に便利です。

Wearにインストールするアプリ次第でさらにいろいろなことも出来るので、今後が楽しみです。

Android Studio 0.5.0がCanary Channel (いわゆる人柱向け)で公開されましたが、0.4.x時とはbuild.gradleのファイルの書き方などが違うので、移行(マイグレーション)の作業が必要です。

特に0.4.2からのアップデートの場合、公式サイトの情報だけでは足りない(気づきにくい)部分があるので、簡易に手順をまとめておきます。

gradle plugin を0.8(0.7)から0.9へ変更

当然ですが、まずはgradle pluginのバージョンを変更します。以下は例です。

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:0.9.+'
    }
}

SDKのアップデートでbuild toolsの19.0.3が出ているのでそれをインストールして、こちらも最新版を参照するようにしましょう(前のバージョンでもしばらく大丈夫じゃないかとは思いますが)。

android {
    compileSdkVersion 19 // お好みで
    buildToolsVersion "19.0.3"

    // ... 以下他の設定
}

公式サイトに移行ガイドが提示されていますが、ポイントは2つです。

• instrumentTestXXX という記述を androidTestXXX に書き換える
• ライブラリプロジェクトの記述を書き換える

src/instrumentTest というフォルダを使用している場合は、そのフォルダ名をandroidTestに変更してください。build.gradleで、instrumentTest.setRoot()で別のフォルダを指定している場合、androidTest.setRoot()に書き換えます。

//instrumentTest.setRoot('tests')
androidTest.setRoot('tests')

上記、以前にEclipseからbuild.gradle ファイルを生成した場合には含まれているはずです。

また、instrumentTestCompile も同様にandroidTestCompileに書き換えます。

ライブラリプロジェクトは変更の必要があればガイドに従ってください。

gradle-wrapper.properties の変更

公式サイトで配布されているAndroid Studio 0.4.2の場合、gradleプラグインの0.7を使用しているはずです。プラグインの0.7ではgradleの1.10は非対応だったので1.9を使っているでしょう。

ラッパーを通じてgradleを使っている場合、ラッパーが取得するgradleのバージョンを1.10に上げる必要があります。

プロジェクトの gradle/wrapper/gradle-wrappper.properties ファイルの以下の部分を書き換えます。

distributionUrl=http\://services.gradle.org/distributions/gradle-1.10-all.zip

以上です。