2016年07月19日

Android Studioを共有環境に入れよう!

ここでいう共有環境とは、以下のような特徴を持つ七面倒くさい環境を言う。
  • ユーザ個人の情報は Z ドライブにネットワークマウント( SMB で)される。数 GBくらいまで入る。
  • マシンのユーザプロファイル領域は高々数十 MB まででリミットがかかる。
  • ネットワークがプロキシ経由のみ。
  • 誰が何するか分かったものじゃない。
  • 通常利用時は、再起動すると C ドライブがロールバックする。もちろんインストール作業をする場合などはその機能を切れる。
  • ロールバックするので、ユーザプロファイルも消える。

ここまで書くとどこのことか分かるかもしれないが、まあ分かったところでさほど問題がないので気にしないことにする。
誰かが同じような環境にいないとも限らないわけで。


普通に使うと割と便利な Android Studio も、こんな環境では割と地獄になる。


普通に使おうとすると発生する問題


問題は致命的なものがいくつか発生する。一つずつ見ていこう。
  1. Android Studio の設定ファイルが C ドライブのユーザプロファイル以下に作られる(環境変数の有無にかかわらず)。何かのキャッシュが入っているためかそこそこ大きく、プロファイル領域を圧迫(というか平然とキャパオーバー)し、さらに再起動で消える。
  2. 設定しないとインストール時にユーザプロファイル以下に Android SDK を置こうとする。数百 MB である。以下同文。
  3. 起動後に始まるダイアログが、インストール時にどこに置いたかなど全く見ないで、ユーザプロファイル以下に Android SDK があるかを調べ、なかったらこちらが指定するか、さもなくばインストールするぞといってくる。入れたら以下略。しかも、ネットワークにつながっていると最新のファイルをダウンロードしてきて更新しようとする。
  4. ビルドに使う Gradle がユーザプロファイル以下に .gradle というフォルダを作り、そこに設定やらキャッシュやらを貯め込む。他に比べれば大きくないが、ほとんど何もしないプロジェクトでも20MB程度使い、残念ながらこちらの環境ではキャパオーバーする。
  5. プロキシの設定が自動でされないため、ビルド時に Gradle が依存するライブラリを取りに行く際に止まる。拒否されるのではなくタイムアウト待ちになるので、ビルドがちっとも終わらない。当然、長く待った挙げ句にエラーになる。さらに、ネットワークにつながっていると環境をアップデートしようとする。再起動すると戻るのに。
  6. プロジェクトを作るデフォルトの位置が C ドライブのユーザプロファイル以下に AndroidStudioProjects というフォルダになっている。間違ってここに作ると再起動時に消える。そもそもファイルサイズが以下略。

もうインストールやめてもいいだろうか・・・?
いやいや、問題を片付ければ使えるかもしれないじゃないか。続けよう。


問題回避


では一つずつ解消しよう。

  1. Android Studio の設定ファイルの位置は Android Studio をインストールしたフォルダの bin の下にある idea.properties を編集すれば良いようだ。あまり直接はいじらないらしいが、全体としてそうしたいので何も思わない。個々で設定は変えたいので、 Z ドライブ以下に作るようにした。
  2. インストール時には Android SDK を C ドライブの皆が見える位置にインストールする。インストール時に指定するだけなので簡単。
  3. 起動時の Android SDK に関するダイアログについてはスキップするようにした。 idea.properties に disable.android.first.run=true と入れるとスキップできる。どこに書いてあるんだそんなこと。
  4. GRADLE_USER_HOME という環境変数に位置を指定すれば Gradle の設定の位置を変えられるらしいので環境変数を追加した。
  5. Gradleの設定に Offline work というものがあった。これを指定すればネットワーク待ちは回避できる。指定させるのは面倒なのだが、現状設定方法が分からない。
  6. プロジェクトの位置は一度作れば設定ファイルにその場所を格納するので、一度目に口酸っぱく Z ドライブに作るよう言うしかない。これもデフォルト指定ができれば良いのだが、方法が分からない。

さて解決したか・・・と思いきや、まだ問題が発生する。


問題回避による問題


回避策によって起こった問題は以下のもの。
  1. 上の 3 のダイアログスキップの影響で、最初に Android SDK の位置を別途指定する必要が出てきた。
  2. 上の 5 の Offline mode の影響で、依存性解決が出来ない。プロジェクトが最初に作るユニットテスト用の junit も見つからない。
  3. 上の 6 のプロジェクトがネットワークドライブ( SMB )上にあることで、ビルドが極端に遅い。ローカル HDD と比較して 60 倍くらい(秒→分で良い感じ)。どうもファイル一覧の取得が必要になって死ぬほど遅くなってるらしい。

そろそろめげてきただろうか。
しかし回避しなければならない。
  1. 仕方ないので Android SDK のパスを指定させることに。幸い SDK の位置なしにはプロジェクトを作れないので、そうそう問題は起こるまい。
  2. 依存性解決のために、 jar を配置したフォルダを指定する Gradle のスクリプトを配置することにした。 Android Studio をインストールしたフォルダの gradle\gradle-2.10\init.d というフォルダに置かれたスクリプトが必ず実行されるらしいので、そこに allprojects { repositories { flatDir { dirs 'ほげほげ' } } } という記述を入れたファイルを置いた。
  3. 遅いのはビルドの時だけだったので、ビルドディレクトリの指定をした。先ほどの gradle のフォルダに置いたファイルに gradle.projectsLoaded { rootProject.allprojects { buildDir = "C:/Users/${System.env.USERNAME}/AppData/Local/Temp/${rootProject.name}/${project.name}" } } と指定。幸いテンポラリフォルダはプロファイル領域から除外されていたので動く。

次にいこう。まだ終わらない。
  1. 上の 2 の jar の無理矢理な指定のせいで、ユニットテストが動かない。本来はプロジェクトフォルダの app\libs に入れるはずなので、ここに必要なものを持ってこないといけない。
  2. 上の 3 のビルドディレクトリ指定により、再起動時に消えることになる。それを試すと、起動時にあらゆるシンボルの解決に失敗する。なお、ビルドはできる。
  3. ビルドディレクトリの問題か、 Android Studio がある生成物である jar ファイルのロックをかけたまま離してくれない。(フルパスを途中からだけ書くと、 appcompat-v7\23.3.0\jars\classes.jar という名前)

これは解決できるのかって?結果を見てみよう。そろそろ年貢の納め時らしい。
  1. 残念ながら現状回避策なし。試しに必要とおぼしき jar ファイルをいくつか libs の中に入れてみたが、なにやらエラーが出た。もう体力がないので今回は断念。つまりユニットテストをするな、と。(投げやり)
  2. ビルドメニューから Make Project をして、 Fileメニューにある "Invalidate Caches / Restart..." から、 Invalidate and Restart を選ぶ。 Android Studio が再起動するが、環境に問題がなければ、再起動後に indexing が行われてシンボルが解決できるようになる。
  3. 未だに回避策不明。 instant go のせいという Stackoverflowの回答もあったが、どうやらそれではない様子。ロックを強制的に解除するプログラムを使う手も説明されていた。ちょっと怖い。(これ実行に管理者権限いらない?)

というわけで、問題が残ってしまった。


現状


割とどうでも良い制限は以下。
  1. 初回に Android SDK の位置を指定する必要がある。
  2. Gradle の Offline mode を指定する必要がある。
  3. 初回に C ドライブにプロジェクトを作らないようにしないといけない。

そして致命的な問題が以下のもの。
  1. Gradle が jar を消せずに失敗する。回避策不明。 Gradle のメニューから別途ビルドすれば出来なくはないが・・・
  2. ユニットテストができない。もう勘弁してほしい。

現状は以上の通り。解決すれば書き換えたりするかも。続きを読む
posted by chiguri at 20:00| Comment(0) | PC

2016年05月23日

WerckerのBoxの使い方(変更に巻き込まれた話2)

前回はカスタムしたBoxの作り方がずいぶん変わってしまったという話をしたのだが、実は使い方も変わっていたという話。
経緯はほぼ同じ。新しく作ったらBoxの設定ができなかった。

あまりにわからなかったので、サポートにメッセージ投げたら
「Wercker classicのサポートそのうちやめるよ。できれば早く移行してね。一応今は、やりたかったらstep作ってからprivateにし直したらできるよ。」

またstep作るんかい!!

step作るときは、対象のリポジトリがpublic repositoryしかダメなので注意。
リポジトリがprivateだったら、こっそりpublicにして、werckerのstep作って、deploy target消して、stepの設定でprivacyのところをprivateにして、リポジトリへのアクセス方法をdeploy keyに変更して、リポジトリの設定をprivateに直して、さあtrigger。またはgit push。
リポジトリがpublicだったら、werckerのstep作って、deploy target消して、stepの設定でprivacyのところをprivateにして、trigger。

いい加減classicから離れる方法を調べないとなあ。
posted by chiguri at 22:32| Comment(0) | 雑多

2016年05月11日

Werckerのboxの作り方(変更に巻き込まれた話)

Werckerというのは、非常に荒っぽくいうと、githubやbitbucketのリポジトリにpushした際に、ある特定の環境でビルドできるか確かめたりテストしたり、ということができるサービスの一つである。
他にも似たようなものはあるが、Werckerの良いところは、無料、bitbucketに対応、プライベートリポジトリにも対応、自分でboxが作れる、という点だろうか。

で、一昨日からboxを作ったりしたのだが(OCamlが入ってる環境が見つからなかったので作っただけ。実際はOCaml入れてCoqをビルドしたりするboxもあるので入ってはいるはずなのだが。)、そのときは検索をかけて見つかる情報通りに作って正しく作れた。
しかし、昨日Prologのboxがないことに気づいて作り始めたところ、何度やっても失敗してしまうようになった。

そもそも、一昨日作ったapplicationと昨日作ったapplicationで、表示されるオプションが全然違う。
ビルドに成功しないから展開(deploy)もできない。
ひたすら環境構築の部分でNo wercker.yml exists!とエラーを出し、ビルドに失敗した旨のメールを自分に送り続ける時間。
一体なんなんだこれは!と家で叫んだりした。

そして今日、一昨日付のこんな記事を見つけた。なんか新しい機能の紹介らしい。
多分、これが昨日自分のアカウントでも有効になったのだろう。
で、この記事の中に、ちょっとだけ「(stepの)deployとかするのはcreate stepでやってね」と出てきた。

みんな(werckerの公開してる有志の?資料でも)「Applicationを作ってビルドしたら成功するよね。じゃあ・・・」と書いてるのに。
記事にちょっとだけ「Step作ってね。」である。
ちゃんと書け。

それに気づいてcreateで選ぶものをApplicationからStepにしたところ、問題もなくbuild、deployできた。
とりあえず、という程度ではあるが、SWI-Prolog用のboxができた形である。
気が向いたら使ってみてほしい。(まだテストもしていない)
posted by chiguri at 13:52| Comment(0) | PC

2016年03月25日

LinuxホストのVirtualBoxのフォルダ共有でこけた

タイトルが長いのは気にしない。
その内容の通り、LinuxをホストにしたVirtualBoxでWindows 7をゲストにしたら困ったという話。

実のところ、別にLinuxがホストだろうとインストールはスムーズにいき、(環境が32bitのせいで)メモリに苦労するものの動いてはいた。
しかし、いざ共有フォルダをつくったらまずいことが起こった。
explorerからファイルをコピーしようとするとエラーが起こるのだ。
具体的には「エラー0x80070057: パラメーターが間違っています。」だ。
ちなみにメモ帳で開こうとしてもほぼ同じエラーが出る。なんだこれは。
しかもコマンドプロンプトで適当にリダイレクトするとファイルが作れるのだ。
さらに、copyコマンドも正常に働く。
移動、削除はexplorerからも可能。
一体何が起こっているのだ。

検索しても検索しても「バックアップで失敗する」話ばかりで何も分からなかったのだが、一つ気になるものがあった。
"Code 0x80070057 The parameter is incorrect" error when you try to display a user's "effective access" to a file
これだ。
effective accessと言われてもさっぱり分からないが、しかしエラーとユーザーのアクセスという点で一致する。
中を読むと大まかにはこういうことが書いてある。

SMBを使った共有フォルダについて、\\host\dirみたいな書き方をしたやつでアクセスする場合を考える。ここで相手のSMB提供プログラムがMSのじゃない場合、ファイルのオーナーをパラメータとして要求してくる。しかし、explorerはオーナーを書こうとしないからエラーが返ってくる。これがそのままユーザーに渡される。実は、SMBの仕様上はオーナーの部分は必須ではないのだが、これを必須とするシステムもある。

今回のにぴったりな状況だ。SMBを提供しているのはVirtualBox、アクセス先は\\vboxsrv\hoge、「パラメーターが間違っている」というエラーメッセージ。
さて、この文書は解決策としてパッチの存在が書いてある。
ただし、Windows8.1以降。

8.1以降。

今入れたの、7なんだが。
え、パッチないの?
まじで?え??

・・・Linuxの方にSamba入れてホストオンリーアダプタで対処することにしよう・・・
posted by chiguri at 00:36| Comment(0) | PC

2016年02月20日

ZenPad 7を買った

Nexus7(2013)の画面を割ってしまった(2年振り?3回目)
修理に12k円もかかるのを三回もやったらさすがにちょっとやっていられないので、新しいのを購入することにした。
ZenPad 7といっても、2015年12月に出たARMのLTE使える方のやつである。
(7と言うと大分前にIntel入ってるのが出ているが、そっちはLTE不可)

とりあえず使った感想なのだが、まずNexus7のときに比べて、白飛びする。
解像度が低いのはわかっているし、さして気にもしないのでいいのだが、どうにも明るめの画像を見ると白になってる部分が。
Nexus7のときは気にならなかったし、他の画面と見比べてもZenPadのときだけ思うので、多分白飛びだと思うんだけどなあ・・・
次に、Androidデフォルトのアプリとほぼ同じような別のASUS製アプリが大漁に入っている。
いらぬ。無効にしかできないのが歯痒い。
UIはNexus7のときと似ているようで違う。ちょこちょこ引っかかるなあ。
カメラ、試してない。オートフォーカスがあるらしいのだが・・・(カメラアプリどこいったかな・・・)
後は現状さほど気にしていない。まあこんなものだろう。

ただ、久々に新しめのSDカードが入るAndroid端末を使って思うのだが、内蔵ドライブを特別扱い「しすぎて」いて、内蔵が小さいとやっていられない。
アプリ(のデータの一部)をSDに移す機能が使えることもあるが、やたら領域を食うのは大体が「後でダウンロードしたデータ」であって、「最初に入っているデータ」ではない。
SDに移せるのは「最初に入っているデータ(の一部)」なので、何の役にも立たず。
Kindleとかそこそこ買っているので、5GBを越えて内部を圧迫。つらい。
専用にフォーマットとかでもいいから、SDカードをもう少しまともに扱わせてくれないだろうか。
(Rootを取ればなんとかする方法もあるようだが、もしかしてRoot取りっぱなしじゃないとダメじゃないのこれ?と首を傾げているので今のところ試す気なし。symbolic linkを作るのかな?ならシェルからいける気がするけど)

うーむむむ・・・

追記:Rootはまだ取れなさそうだ。
ext3にフォーマットするとSDカード挿入ではマウントしてくれないし、仕方なくext3のパーティションを15GBほど作ったが、マウントできないのでやっぱり無用・・・
Root取れるようになったら試したいところではあるが・・・
posted by chiguri at 16:12| Comment(0) | 雑多