Bescottee » eclipse http://andbrowser.com 苦しいときは伸びてるとき、楽なときは伸びていないとき Sat, 06 Jan 2018 14:12:26 +0000 http://wordpress.org/?v=2.9.2 en hourly 1 ADT(Android Developer Tools) ダウンロードURL一覧 http://andbrowser.com/development/918/old-adt-download-url/ http://andbrowser.com/development/918/old-adt-download-url/#comments Sun, 21 Dec 2014 05:00:56 +0000 admin http://andbrowser.com/?p=918

Android ADTは新しいバージョンが続々と登場してきます。そうすると、Android SDK の ADT install サイトから古いもののダウンロードリンクが無くなってしまいます。但し、eclipseのバージョンや過去のプロジェクトを古いADTで急にバージョンアップしたい場合などに急に必要になることがあります。そのため、以下に古いADTのリンクを作成しておきます。これでいつでも素早く古いADTもダウンロードできます。

ADTの最新プレビュー版を利用したいという猛者の方は、Android Tools Project Site Preview Channel にダウンロード方法が記載しているのでご覧ください。

最新版のADTをインストール後に問題が発生して、古いADTに戻したい場合は、[Android TIPS]　旧バージョンで開発環境を構築するやAndroidSDKToolsのrevisionとADTのバージョンを下げる方法の記事が参考になると思います。AndroidSDKToolsのrevision20にしたらエライ目にあった という方も居られるようですので。

過去のADT のダウンロードURL一覧

  • ADT 21.1.0 (February 2013)
  • ADT 21.0.1 (December 2012)
  • ADT 20.0.0 (June 2012)
  • ADT 18.0.0 (April 2012)
  • ADT 17.0.0 (March 2012)
  • ADT 16.0.1 (December 2011)
  • ADT 16.0.0 (December 2011)
  • ADT 15.0.1 (November 2011)
  • ADT 15.0.0 (October 2011)
  • ADT 14.0.0 (October 2011)
  • ADT 12.0.0 (July 2011)
  • ADT 11.0.0 (June 2011)
  • ADT 10.0.1 (March 2011)
  • ADT 10.0.0 (February 2011)
  • ADT 9.0.0 (January 2011)
  • ADT 8.0.1 (December 2010)
  • ADT 8.0.0 (December 2010)
  • ADT 0.9.9 (September 2010)
  • ADT 0.9.8 (September 2010)
  • ADT 0.9.7 (May 2010)
  • ADT 0.9.6 (March 2010)
  • ADT 0.9.5 (December 2009)
  • ADT 0.9.4 (October 2009)
    • ]]> http://andbrowser.com/development/918/old-adt-download-url/feed/ 30 CrashlyticsでAndroidアプリの品質向上を実現 http://andbrowser.com/development/2339/andrpid-app-use-crashlytics/ http://andbrowser.com/development/2339/andrpid-app-use-crashlytics/#comments Wed, 07 May 2014 09:15:36 +0000 admin http://andbrowser.com/?p=2339

    Crashlyticsとは？

    CrashlyticsはAndroid, iOSのアプリ開発向けにクラッシュレポートなどの情報をレポートしてくれるウェブサービスです。Android, iOS向けに簡単に組込みができるライブラリも準備されています。レポートを見る画面などは以下のようにとても綺麗にデザインされており、いま風なUIになっています。

    アカウント作成


    トップページの上記の項目に名前とメールアドレスを入力するとアカウント登録が行えます。但し、アカウント登録はすぐに完了するわけではなく、名前とメールアドレスを入力するとwaiting listに掲載されるようで、後日メールでアカウント登録の返事が届きます。

    私の場合は夜に実施して、翌朝起きたら以下のようなHTMLメールが届いていて、アカウント登録ができました。

    Android向けのSDKの入手

    アカウント登録後にCrashlyticsにログインして、Android用のSDKを入手します。以下のようにAndroid Stdio用、Eclipse用、Intelli J用の3種類が用意されています。今回は Eclipse用を利用します。

    Eclipseの場合、eclipse pluginの形式でSDKが提供されます。インストールは簡単で、eclipse pluginをインストールする方法の
    Eclipseのメニューの以下のように Help -> Install New Softwareから選択し、「https://crashlytics.com/download/eclipse」を入力します。

    あとは、Eclipse pluginの仕組みにのっとってインストールを行います。インストールが完了すると以下のようにツールバーに Crashlytics のアイコンが表示されます。

    Eclipse ProjectへのSDKの適用

    アイコンをクリックして、Crashlytics にログインします。

    Eclipse Package Explorer で表示されているプロジェクトが以下のように表示されるため、Crashlytics の SDKをインストールしたい Project を選択します。

    ここからが素晴らしいポイントなのですが、このpluginは libs フォルダへのcrashlytics.jarのインストールだけでなく、いくつかの必要なコードの追加まで自動的に実施してくれます。但し、これによる副作用もあるため、それについては後述します。

    自動的に追加してくれるコードは以下のものになります。

    • AndroidManifest.xml の中に <uses-permission android:name=”android.permission.INTERNET” />と <meta-data android:name=”com.crashlytics.ApiKey” android:value=”?????????”/> の追加。(????の部分はpluginが自動的に適切な値をいれてくれます）
    • ホームアプリから起動されるActivity の onCreate() の中に Crashlyticsの初期化コードを追加。具体的には、Crashlytics.start(this); の1行。
    • res/values/com_crashlytics_export_strings.xml ファイルを自動的に追加。中身がビルドするたびに変更されるため、SCMの管理対象外とします（.gitignore に追加）

    なお、追加される API key の発行がアプリ単位ではなく、Company 単位だそうです。

    自動的に追加された状態でアプリ内で発生した Exception などの情報をCrashlytics SDKが取得して裏でWebサービスへのアップロードを実施してくれます。自分の検証だけでは発見しづらい、環境面による Exception などの情報をウェブサービスや Pluginから見れるようになります。しかも、Daily でメールで1日のcrash情報のサマリーが送られてくるので忘れずに確認することができます。

    注意点

    Pluginが上記のように自動的に必要なコードを追加してくれるのはうれしいことなのですが、以下のような課題もあるため注意が必要です。

    • 文字化け対策
    • 初期化コードの追加漏れの対策
    文字化け対策

    コメントなどに日本語が入ったソースコード（UTF8で保存済）に対して、Eclupse Crashlytics pluginが自動的にコードが追加した場合に文字化けが発生。そのため、そのような場合は、手動で初期化コードを追加しましょう。Crashlytics.start(this);を追加する場所は、onCreate() の super.onCreate(savedInstanceState); の後で setContentView(R.layout.detail_main);の前に追加されるようなので、その場所がよいでしょう。

    初期化コードの追加漏れの対策

    ホームアプリから起動されるだけでなく、Intent 連携などで起動されるアプリの場合、その起動されるActivity(*2) の onCreate()などの中に手動でCrashlytics.start(this);を追加しましょう。起動されるActivity(*2) がホームアプリから起動されるActivity(*1) の次に呼び出される場合とIntent連携で直接呼び出される場合がある場合でも、Crashlytics.start(this);の中で適切な処理が実施されており、2回呼び出されても問題ないそうです。

    試しに Crash を起こしてみる

    正しく crash が通知されるかどうかを確かめるために、onCreate()の中でわざとexception を追加して、crash report を受領してみましょう。
    以下のようなコードを onCreate()の最後に追加します。

    throw new RuntimeException("This is a crash");

    追加したあとに eclipse からビルド、インストール、実行をすると起動時にexceptionが発生します。その後、http://www.crashlytics.com/にログインすると、以下のように確認できます。

    レポートの中身

    レポート画像には以下の情報が記載されます。

    • クラッシュの発生日付と数
    • 端末の種類
    • OS Version
    • 端末のルート化の有無
    • 内部ストレージの容量、割合
    • RAMの容量、割合
    • APP IN FOCUS(？）（想像：ユーザが利用中に発生した or 裏で発生したかどうか）
    • PROXIMITY IN（？）（近接センサーの設定有無）
    • 端末の向き
    • バッテリー残量
    • クラッシュ時のスタックトレース


    しかも、crash report はウェブサービスだけでなく、以下のように Eclipse の Crashlytics pluginからも閲覧可能です。pluginから該当する crash を選択するとウェブサービスのほうで詳細なレポートを確認できます。

    クラッシュレポート以外の利用方法

    クラッシュレポート以上の使い方として、自由に任意のString, Bool, Double, Float, Int などを保存し、レポートに送信することもできるので、Google Analytics for Android のような特定のActivityが起動されたコンバージョンや閾値を超えた場合のレポートなどにも利用できます。

    Crashlytics.setString(key, value);

    void setBool(String key, boolean value);
void setDouble(String key, double value);
void setFloat(String key, float value);
void setInt(String key, int value);

    Crashlytics.setInt("current_level", 3);
Crashlytics.setString("last_UI_action", "logged_in");

    まとめ

    このサービスをいれてクラッシュレポートが来ると、なぜだかうれしくなり、すぐに修正して、issue を close したくなりますね。それはつまり、いままでユーザの手元で起こっていたexceptionをいままで開発者が知ることもなしに、ユーザの満足度を下げていたことの表れだと思うとユーザに申し訳なく思いますし、会社のアプリだとするとそれだけで競争力の低下につながってしまいます。実際に利用してみるとプロジェクトへの適用の簡便さ、クラッシュレポートのリアルタイム性、レポートの見易さなどがとても良いと感じました。まだ小さな課題はいくつもあるものの、Android Stdio向けのサポートも用意しているということでまだまだ前に進んでいってくれるサービスだと思います。このCrashlyticsはtwitter が買収したこともあり、無料で商用レベルの機能が利用でき、大きな後ろ盾があるため、安心して利用していけると思います。これからのさらなる進化が楽しみです。

    ]]>     http://andbrowser.com/development/2339/andrpid-app-use-crashlytics/feed/ 1     Android Development Tools(ADT) 21.1.0 更新情報 http://andbrowser.com/development/1578/android-development-tools-adt-21-1-0-2/ http://andbrowser.com/development/1578/android-development-tools-adt-21-1-0-2/#comments Wed, 13 Mar 2013 18:13:12 +0000 admin http://andbrowser.com/?p=1578 Android Development Tools(ADT) 21.1.0

    ADT 21.1.0 (2013年2月)

    adt_21.1.0

    依存関係:
    • ADT 21.1.0 を利用するために Java 1.6 かそれ以降が必要
    • ADT 21.1.0 を利用するためには Eclipse Helios (Version 3.6.2) かそれ以降が必要
    • ADT 21.1.0 は、SDK tools r20.0.1 を利用するために設計されています。SDK Tools r21.1. まだSDK Tools r21.1をインストールしていない場合は、SDK manager からインストールしてください。
    一般連絡:
    • noticationsと brank fragment と list fragments の新しいコードテンプレートを追加
    • リソースの名前変更のリファクタリングをサポート。XMLファイルや drawable アイコンや R.フィールド名やIDのレイアウトエディタ内のものに対するリファクタリングを実施すると参照しているものも更新されます。
    • 15以上の新しい Lint check を追加。古い APIの override に関するチェックや、XMLリソースの問題や、graphic asset に関する項目やmanifest タグに関するもの。
    • Refactor > RenameのメニューのようなリファクタリングのショートカットキーをXMLエディタに対して更新。
    • ダブルクリックのハンドリングの改良をXMLエディタに対して実施
    • カスタムビューやテーマ参照やクラス参照に関するコード補完を追加。例えば、<fragment android:name=””> タグに対して、フラグメントクラスの一覧を提案するようなものです。同様に、マニフェスト上で入力に対する最適な提案も行われます。
    • すべてのインポートできるプロジェクトの一覧からプロジェクト名を編集できるようにするための Project Importダイアログの更新。
    • レイアウトエディタのlayout aliasesのサポートを追加
    不具合修正:
    • パッケージやクラスの名前変更や移動に関するリファクタリングに関する項目を修正
    ]]>     http://andbrowser.com/development/1578/android-development-tools-adt-21-1-0-2/feed/ 2     Android Lint 解析内容の詳細を調査 http://andbrowser.com/development/knowhow/787/android-lint-check-rule-detail/ http://andbrowser.com/development/knowhow/787/android-lint-check-rule-detail/#comments Sun, 25 Dec 2011 12:54:11 +0000 admin http://andbrowser.com/?p=787 android lint check detail

    Android Lintの解析内容の詳細

    Android Lintについては、前のエントリをご参照ください。このエントリでは、以下のlintコマンドで表示される lint の解析内容をカテゴリごとに整理し、指摘事項の詳細をまとめました。。

    $ lint --show

    以下の詳細を見る前にいくつかポイントを整理しておきます。

    • 優先度(Priority)は数字が大きい（10が最大）ものが高いことを意味します。
    • 重要性（severity)は変更可能。全プロジェクトのみではなく、各プロジェクトごとにも設定可能。変更は、eclipse > preference > Android > Lint Error Checking で実施。
      android lint preference

    • セーブ時に一部チェックの自動適用の可否を設定可能
    • アプリパッケージ作成時のフルチェックの可否を設定可可能
    • 指摘項目は適時更新されて追加しているため、掲載不足のものもあります。それらは、lint --showコマンドか preference の Lint Error Checking で詳細をご覧ください。
    • エラーが発生すると apk 作成を中止するため、重要性(severity)を警告からエラーにする場合は熟慮することをお薦めします。

    Lintの解析項目一覧

    カテゴリ
    Category    		 ID 概要
    Name    		 優先度
    Priority    		 重要性
    Severity    		 詳細
    Detail
    正確性 AdapterViewChildren XML内の子Viewとして定義されていない AdapterView かどうかを調査 10/10 警告 ListViewのようなAdapterViewは、ListAdapterのようなもので、Javaコードからデータを設定しなければなりません。より詳細は、http://developer.android.com/reference/android/widget/AdapterView.htmlを参照ください。
    正確性 MissingPrefix Androidネームスペースで利用されていないXML属性を発見 8/10 警告 Android viewたちのほとんどは、Androidネームスペースの属性をもっています。これらの属性を参照する場合は、必ずネームスペースの接頭語をつけるべきです。さもないとカスタム属性として aapt に解釈されます。
    正確性 MissingTranslation 全文字列が翻訳済みかどうかの完全性を調査 8/10 エラー もしアプリが１言語よりも多い言語をサポートする場合、１言語の全文字列が他の言語にも翻訳されているべきです。標準では、この検出は　言語の地域たちに提供されます。ちょど文字列のサブセットとして提供されたり、標準の言語文字列の代替になります。すべての地域に対して、完全な翻訳を提供するために ANDROID_LINT_COMPLETE_REGIONSという環境変数をセットすることによって、強制できます。
    正確性 Proguard proguard.cfg ファイルの問題を調査 8/10 エラー proguard.cfg ファイルで -keepclasseswithmembernames を利用することは、正しくありません。なぜなら、ADTの新しいバージョンで作成される proguard.cfg ファイルは異なるフォーマットになるためです。
    -keepclasseswithmembernames の代わりにkeepclasseswithmembers を利用してください。なぜなら過去のフラグもまた、XMLからでJava(CustomViewsのようなもの)でなく参照されるシンボルのみの"allow shrinking"を示しているためです。
    より詳細情報は、http://code.google.com/p/android/issues/detail?id=16384 を見てください。
    正確性 ScrollViewCount ScrollViewが正しく子ウィジェットが保持しているかを調査 8/10 警告 Scrollviewは1つの子ウィジェットのみを保持できます。もし２つ以上の子を持ちたければ、コンテナレイアウトにまとめて保持させましょう。
    正確性 DuplicateIds シングルレイアウトの中で同じIDが存在するかどうかの調査 7/10 警告 レイアウトの中で、IDは一意であるべきです。さもないと findViewById() が予期せぬviewを返します。
    正確性 InconsistentArrays 配列の要素数に矛盾がないかどうかを調査 7/10 警告 配列が他の地域向けに翻訳されるときに、一般的にはオリジナルな配列と同様の要素数にすべきです。配列を追加や削除したときに、すべての地域の更新を簡単に忘れてしまいます。そんため、lint の警告はこれらの矛盾を検出します。

    注意：しなしながら本当にそれぞれの設定において（例えば、存在するオプションに相当する配列やそれらのオプションが異なるレイアウトの向きやそれ上の違いがある場合）配列アイテムの要素数が異なるものを利用したい理由がある場合は、自らの判断でエラーかどうかを判断して利用してください。
    もし間違ったエラーがプロジェクト内にある場合は、そのエラータイプを抑止できます。
    正確性 NestedScrolling スクロールするウィジェットが何かのスクロールするウィジェットの中に入っているかかどうかを調査 7/10 警告 ScrollViewのようなスクロールするViewは、重要なユーザビリティ問題のため、何かのネストされたスクロールウィジェットを中に含めるべきではありません。
    正確性 ScrollViewSize ScrollViewがスクロール範囲の中で WRAP_CONTENT を利用しているかどうかをチェック 7/10 警告 ScrollView の子たちは、layout_width か layout_height 属性に wrap_content よりもむしろ fill_parent か match_parent をスクロール領域の中で指定すべきです。
    正確性 DuplicateIncludedIds include tag を利用して結合したレイアウトにわたって同じIDが利用されているかどうかをチェック 6/10 警告 同じIDを２つの独立したレイアウトに利用することは良いことです。しかしながら、もしレイアウトを include tag して結合した場合、IDはincludeされたレイアウトの連鎖の中で一意な必要性がある、もしくはActivity#findViewById()は期待しないViewを返します。
    正確性 ExtraTranslation 利用されていない（標準言語向け文字列で存在しない）ように見える翻訳をチェック 6/10 警告 もし、ある文字列が特定の言語向けの翻訳ファイルで現れた場合で、標準の地域(locale)に同じ文字列が存在しない場合があれば、たぶんこの文字列は利用されていないだろう。（あなたのアプリが特別な地域(locale)のみで動作するように意図したものであれば、技術的にこの可能性がありますが、しかし代替を準備するよりはまだまだ良案です。）
    正確性 ManifestOrder <application>タグの後ろに<uses-sdk>が存在するようなマニフェストの問題を調査 5/10 警告 <application>タグは、必要なversion情報やfeatureやlibrariesなどの宣言タグの後に現れるべきです。
    <application>タグがいくつかの他のタグより前に現れたときは過去に複雑なバグが存在しました。
    そのためロジカルな依存順序でマニフェストに並べるのがベストです。
    正確性 StateListReachable <selector>の中で到達できない状態(state)を調査 5/10 警告 selectorの中で、state list の最後の子のみが state修飾詞を除外すべきです。もしそうでなければ、リストのすべての次にくる項目は与えられた項目がすべてマッチするために無視されるでしょう。
    正確性 GridLayout 行と列が外部で宣言されているような場合のGridLayoutの潜在的なエラーを調査。 4/10 エラー GridLayoutのrowCountかcolumnCountのサイズの宣言が外部のlayout_rowやlayout_columnで定義されている場合、たいてい故意ではないエラーになります。
    正確性 PxUsage "px"単位の利用を調査 2/10 警告 パフォーマンスの理由とコードをシンプルに保つために、Androidシステムは指定された範囲のスタンダードなユニットや指定された値のためにピクセルを利用します。
    この意味はviewの範囲はいつもピクセルを利用してコード上から設定されますが、しかしいつも現在のスクリーン density をベースに設定されます。例えば、もし、myView().getWidth() が10を返すとき、viewは現在の画面の10ピクセルの横の長さがありますが、しかしdensityの高い画面の端末の場合、15を返す可能性があります。もしアプリの中で現在のスクリーンdensityに拡大されないビットマップとともにピクセルの値を利用していると、自らのコードでビットマップリソースを画面に合うようにスケールさせる必要があります。
    セキュリティ ExportedService パーミッションを必要としない exported Service(<service>タグのandroid:exported="true"の場合）を調査 5/10 警告 Exported services(exported=true か intent-filder を含んでいるか、exported=falseを明示していないか）はパーミッションを定義すべきです。これはサービスを起動するか、バインドするために必要です。これがない場合、アプリはこのサービスを利用できません。
    パフォーマンス UseCompoundDrawables 現在のノードが 複合（compound) drawable を利用した TextView に置き換えられるかどうかを調査 6/10 警告 ImageViewとTextViewを含んだLinearLayoutは、結合したdrawableとして扱われて、パフォーマンスが向上します。
    パフォーマンス MergeRootFrame ルーツの<FrameLayout>が<merge>タグで置き換えられるかどうかを調査 4/10 警告 <FrameLayout>がレイアウトのルートであり、背景やパディングが提供されていない場合、パフォーマンス向上のために<merge>タグに入れ替えできます。
    パフォーマンス InefficientWeight LinearLayout内で無効な weight 指定を調査 3/10 警告 LinearLayoutの中の１つのウィジェットしか weight を定義していないとき、残ったすべてのスペースを割り当てるために、0dpをwidth/heightに設定することによりパフォーマンス向上が見込める。Width/heightに 0dp が定義されている場合は、最初に自身のサイズは計算されません。
    パフォーマンス UnusedResources 未使用リソースを調査 3/10 警告 利用していないリソースは、アプリを大きくし、ビルド時の速度が遅くしてしまいます。

    制限事項：
    -もしEclipseに関わらずコマンドラインからlintを実行している場合、Javaファイルの解析は正確なパースツリーを利用するよりむしろパターンパッチが適応されます。そのため、結果は正確ではありません。（この制限は将来対応予定です。）
    -解析は、ライブラリプロジェクトで定義されているリソースやライブラリプロジェクトが参照しているリソースの間の依存関係を考慮できません。そのとき、リソースはまだ利用されていませんと通知されます。
    パフォーマンス UselessLeaf 削除可能な子要素かどうかを調査 2/10 警告 子も背景も持たないレイアウトは、よりフラットにしたり効果的なレイアウト階層にするために削除できます（invisibleなため）。
    パフォーマンス UselessParent 削除可能な親要素かどうかを調査 2/10 警告 子を持たないレイアウトは、ルートレイアウトか scrollview ではありませんし、背景を持たず、削除可能であり、子たちを親に移動させたり、より効果的なレイアウト階層に変更することができます。
    パフォーマンス TooDeepLayout レイアウト階層が深すぎるかどうかを調査 1/10 警告 レイアウトのネストが深すぎる場合はパフォーマンスを低下させます。そのため（RelativeLayoutやGridLayoutのような）フラットなレイアウトの利用を検討してください。標準の最大の深さは10ですが、この設定は環境変数のANDROID_LINT_MAX_DEPTHで設定できます。
    パフォーマンス TooManyViews viewの数が多すぎるかどうかを調査 1/10 警告 １つのレイアウトにたくさんのViewを使うことは、パフォーマンスを低下させます。統合したdrawableや他の仕組みを利用して、レイアウトのviewの数を減らすように検討してください。
    パフォーマンス UnusedIds 未使用のIDを調査 1/10 警告 重要：この設定はデフォルトで無効です。有効にしたい場合は、–enable UnusedIds を　してください。

    リソースID定義は、どこからも参照されない場合は必要ありません。ID定義を行う場合は、たとえ利用しない場合であっても、レイアウトやメニュー上で簡単に動作するため、悪い考えであり必要ありません。そのため削除したほうがよいでしょう。
    ユーザビリティ TextFields inputTypeやヒント設定の間違ったテキストフィールドを調査 5/10 警告 テキストフィールドにinputType属性が提供されていることは、ユーザビリティの改善に有効です。なぜなら入力されるデータが独立していて、最適なキーボードをユーザに提供できるためです（電話番号のための数字のみや文字のみのように）。同様に、ヒント属性はユーザにテキストフィールドに何を期待するかを表示することができます。
    ユーザビリティ：アイコン IconNoDpi nodpiフォルダとdpiフォルダの両方にアイコンが存在するかを調査 7/10 警告 drawable-nodpiフォルダのビットマップは、Androidフレームワークによってスケールされません。もし同じ名前のdrawableリソースが drawable-hdpiのようなdpiフォルダと同様に-nodpiフォルダに存在する場合、あいまいであり、国際化できない振る舞いになります。
    １つか他のものを削除して、他のアイコンを利用してください。
    ユーザビリティ：アイコン GifUsage GIFファイル（非推奨）が利用されてる画像を調査 5/10 警告 .gifファイルフォーマットは非推奨です。.pngか.jpgの利用を検討してください。
    ユーザビリティ：アイコン IconDipSize densityごとのアイコンたちが概ね同じdensity-independentサイズかどうかを確認 5/10 警告 複数のdensityに提供されるすべてのアイコンがチェックされて、すべてが同じdensity非依存ピクセル(dpi)サイズであることを計算します。これは画像が異なるフォルダに入っていたり、アイコンがいくつかのフォルダが忘れられて新しいサイズに変更されるエラーを検出します。
    ユーザビリティ：アイコン IconDuplicatesConfig 様々設定パラメータを通した同一のビットマップのアイコンを探索 5/10 警告 もしアイコンがdrawable-hdpiか-v11のような異なる設定パラメータで提供された場合、それらは一般的に異なるものです。この検出は、同じアイコンが国際化ではなく異なる設定フォルダーに提供されている場合に動作します。
    ユーザビリティ：アイコン IconExpectedSize ランチャーアイコン、ノーティフィケーションアイコンなどが正しいサイズかどうかを確認 5/10 警告 ランチャーアイコンには事前に定義されたサイズがあります（それぞれのdensityごとに）。これらの規約に従う必要があり、アイコンをプラットフォームごとにフィットさせる必要があります。
    より詳細は、http://developer.android.com/guide/practices/ui_guidelines/icon_design_launcher.html#size を参照してください。
    ユーザビリティ：アイコン IconLocation densityごとのdrawableフォルダに画像が配置されていないことを確認 5/10 警告 res/drawableフォルダは、XML内にshapeで定義されたような density非依存なグラフィックスのために定義されています。ビットマップの場合、drawable-mdpiに移動したり、より高い解像度や低い解像度のものをdrawable-ldpiやdrawable-hdpiやdrawable-xhdpiに振り分ける検討を行いますもし、アイコンが"本当に"density 非依存の場合（たとえば、solid color）、drawable-nodpi フォルダに入れられます。
    ユーザビリティ：アイコン IconDensities すべてのサポートされるdensity に対してアイコンのカスタムバージョンを提供することを確認する 4/10 警告 アイコンは、主要な screen density class(low, medium, high, extra high)のそれぞれに対してカスタムバージョンを提供し、ベストな見栄えになります。このlintは、それぞれのアイコンたちが density の種別を完全にカバーしていないかどうかをチェックします。
    Low density は、あまり多く利用されていないため、このチェックは無視されます。それを強制的に適用させたい場合は、環境変数の値に、ANDROID_LINT_INCLUDE_LDPI=true と設定してください。現在の density の利用方法の詳細は、http://developer.android.com/resources/dashboard/screens.html を参照ください。
    さらなる詳細情報は、http://developer.android.com/guide/practices/screens_support.html を参照ください。
    ユーザビリティ：アイコン IconDuplicates 他の名前でコピーされたアイコンを探索 3/10 警告 もしアイコンが他の名前で再利用されている場合、統合して１つのみを利用するようにしたり、他を削除してアプリをより小さくできます。
    しかしながら、複製されたアイコンは通常国際化されなかったり、ときどき上書きされたり、更新忘れが発生します。
    ユーザビリティ：アイコン IconMissingDensityFolder すべてのdensity フォルダが準備さされていることを確認 3/10 警告 アイコンは、主要な screen density class(low, medium, high, extra high)のそれぞれに対してカスタムバージョンを提供し、ベストな見栄えになります。このlintは、特定フォルダが drawable-hdpi のように間違っていたりすることをチェックします。
    Low density は、あまり多く利用されていないため、このチェックは無視されます。それを強制的に適用させたい場合は、環境変数の値に、ANDROID_LINT_INCLUDE_LDPI=true と設定してください。現在の density の利用方法の詳細は、http://developer.android.com/resources/dashboard/screens.html を参照ください。
    さらなる詳細情報は、http://developer.android.com/guide/practices/screens_support.html を参照ください。
    アクセシビリティ ContentDescription イメージウィジェットがコンテンツの説明を提供しているかどうかを確認 3/10 警告 ImageViewやImageButtonのようなテキストではないウィジェットは、画面でよめたり、他のアクセサビリティツールが十分にユーザインタフェースを保持できるようにウィジェットのテキスト説明文で特定できるように、contentDescription属性を利用すべきです。
    国際化 HardcodedText リソースに定義すべき、ハードコードされた文字列属性を調査 5/10 警告 レイアウトファイル内で直接ハードコードされたテキスト属性は、以下のいくつかの理由により駄目です。
    -コンフィルレーションの種類が作られたとき（例えば、landscapeかportraitかのような）には、正確なテキストを繰り返し利用すべきです。（変更時に最新の状態をキープするため）
    -アプリは既存の文字列リソースを新しい言語に翻訳したいとときにすぐに、他の言語に翻訳できない。

    Antoid Lint はまだまだ開発が並行して進んでいるため、上記のID以外にもこれからどんどん追加されていくと思います。このスピード感と様々なオープンテクノロジーの採用（Lintもそのうちの１つ）が Android 普及の鍵だと感じているので、もっと進んでいってもらいたいと個人的には思っています。

    ]]>     http://andbrowser.com/development/knowhow/787/android-lint-check-rule-detail/feed/ 2     Android Lint の利用方法 http://andbrowser.com/development/knowhow/712/android-lint/ http://andbrowser.com/development/knowhow/712/android-lint/#comments Sun, 18 Dec 2011 12:55:16 +0000 admin http://andbrowser.com/?p=712 Android Lint

    Android Lintの意訳です。完璧な自信はありませんので原文も一緒にご参照ください。

    Android Lint

    Android Lintは、ADT16(とSDK Tools 16)のための新しいツールです。これは、Androidプロジェクトのソースコードの潜在的な不具合を発見するためのものです。このツールは、Eclipseに統合されて利用されます。アーキテクチャは、意図的に IDE と依存関係を持っていません。そのため、継続的インテグレーションシステム(CI)のようなシステムと同様に他のIDEやビルドツールにも統合されることが望まれています。

    以下に不具合の種類をいくつかの例を交えて紹介します。

    • 翻訳の失敗（と、利用されていない翻訳）
    • レイアウトパフォーマンスの問題（以前の layoutopt ツールで発見されていたものとそれより多くのもの）
    • 未使用のリソース
    • 矛盾する配列サイズ（配列がマルチ構成で定義されている場合）
    • アイコンに関する問題（densityの間違いやアイコンのコピーや間違ったサイズなど）
    • ユーザビリティに関する問題（テキストフィールドに入力種類が指定されていないのようなもの）
    • Manifestのエラーに関すること
    • その他、たくさんのこと

    2011/11/24：いくつかの新しい lint ルールを追加

    このドキュメントを参照してください。これには lint で現在チェックされるすべての項目が掲載されています。
    Lint はまだ開発中のため、このリストは将来追加されていきます。加えて、将来カスタムなチェック項目を（できる限り簡単に）追加できるようなAPIを開発しています。

    コマンドライン利用方法

    lintというコマンドラインツールが SDK tools/ ディレクトリに提供されています。
    もしSDK tools/ ディレクトリにパスが通っていれば “lint”を実行できます。
    実行時にAndroidプロジェクトディレクトリを指定してください。任意のディレクトリが指定可能で、(Androidプロジェクトではない場合）再帰的に探索されますし、ディレクトリ内のすべてのプロジェクトがチェック対象になります。（さらにスペース区切りで複数のプロジェクトを指定することもできます）

    $ lint /src/astrid/
Scanning GreenDroid-GoogleAPIs: ..
Scanning stream: ...
Scanning api: ...........................
Scanning GDCatalog: .......................
Scanning GreenDroid: ...........................................................
Scanning tests: ...
Scanning filters: ....
Scanning tests: .....
Scanning astrid: ....................................................................................................................................................
Scanning simple: .......
api/res/values-ca: Error: Locale ca is missing translations for: sync_SPr_bgwifi_key, sync_SPr_forget_key, sync_SPr_interval_values, sync_SPr_logged_in_prefix... (2 more) [MissingTranslation]
astrid/res/values-ca: Error: Locale ca is missing translations for: DLG_cancel, DLG_dismiss, DLG_ok, EPr_deactivated... (117 more) [MissingTranslation]
api/res/values-cs: Error: Locale cs is missing translations for: sync_SPr_bgwifi_key, sync_SPr_forget_key, sync_SPr_interval_values, sync_SPr_logged_in_prefix... (2 more) [MissingTranslation]
(many lines omitted)
43 errors, 466 warnings
    チェックの無効化

    エラーメッセージの後に、鍵括弧（[や]）でエラーの様々な種別を表す id が表示されます。
    上記の “MissingTranslation” のようなものです。
    指定したチェック項目やチェックのリストを –disable オプションを追加することによって無効化できます。
    例えば以下のように。

    Usability カテゴリーの Icons サブカテゴリーのように、上記の “Usability:Icons” の記載を行い、カテゴリーリストを作成できます。
    デフォルトではいくつかのチェックが無効化されています。それらは、 –enable フラグを追加することによって有効化できます。
    最終的に、–check フラグを利用して正確に確認できます。以下のようにコードベース内の特定の問題を見つけられます。

    利用可能な id とカテゴリーは以下のように探せます。

    $ lint --list
Valid issue categories:
Correctness
Security
Performance
Usability
Usability:Icons
Accessibility
Internationalization

Valid issue id's:
"ContentDescription": Ensures that image widgets provide a contentDescription
"DuplicateIds": Checks for duplicate ids within a single layout
"StateListReachable": Looks for unreachable states in a <selector>
"InefficientWeight": Looks for inefficient weight declarations in LinearLayouts
"ScrollViewSize": Checks that ScrollViews use wrap_content in scrolling dimension
"MergeRootFrame": Checks whether a root <FrameLayout> can be replaced with a <merge> tag
...

    各項目の利用方法を取得できます。–show コマンドオプションに id やカテゴリーを指定してください。（引数を省略するとすべての説明が見れます）

    $ lint --show MissingPrefix
MissingPrefix
-------------
Summary: Detect XML attributes not using the Android namespace

Priority: 8 / 10
Severity: Warning
Category: Correctness

Most Android views have attributes in the Android namespace. When
referencing these attributes you *must* include the namespace prefix,
or your attribute will be interpreted by aapt as just a custom
attribute.
    HTML レポート

    コマンドラインツールからHTMLレポートも作成できます。生の lint 出力よりもいくつかの以下の利点があります。

    • 各項目ごとにより詳細な説明が記載されます。それにハイパーリンクを用いて各項目の属性やより詳細情報を提供できます。
    • エラーが存在する実際のソースコードを掲載できます（エラーの周りの3行程度）
    • ソースファイルを結合するリンクを含められます。
    • アイコンエラー時に、比較できるようにそれぞれのアイコンをサポートされます。

    HTMLレポートを作成するために、–html filename の引数を追加してください。

    $ lint --html /tmp/report.html

    By default, links to source files will just use local file:// path resources. You can remap the URLs to a different prefix with the –url option. For example:

    デフォルトでは、ローカルファイルの file:// パスを利用してソースファイルをリンクします。–url オプションを利用して異なる接頭語を利用して URL にリンクできます。

    $ lint --html /tmp/report.html --url /src/MyProj=http://buildserver/src/MyProj
    その他のコマンドラインオプション

    "lint --help"を実行すれば、詳細情報や利用可能なオプションが表示されます。

    Eclipse での利用方法

    Lint は ADT 16 に統合されています。これによって lint のコマンドラインバージョンの上記のような機能が提供されます。

    • 多数の警告の自動的修正。
    • Lint が様々な編集時に自動的に実行されます。
    • エラーの特定事例と同様にエラーを抑止する機能があります。
    • 厳格に項目を設定する機能があります。
    • lint view から問題のソースコードに直接ジャンプできます。
    Lintの自動実行

    Lint は以下の場合に自動的に実行されます。

    • APKを作成時。この場合、lint は致命的なエラーのみの調査を行う特別なモード（高速に実行するため）で実行されます。そして、もし致命的なエラーが有る場合はapk作成が中止されます。この機能は Lint オプションで停止できます。
    • レイアウトファイルや manifest ファイルのようなXMLファイルを編集や保存した場合。この場合、すべてのファイル内で調査が実施されて、調査結果がエディタのマーカーとして表示されます。
    • レイアウトエディタを利用する場合。UI操作を行うたびに、ファイル内調査（layouoptの様々なルールのような）がレイアウトファイルに実行されて、lint window(レイアウトエディタの上部の左コーナーに表示されるエラーやマーカーから開いたり)が表示されます。
    Lint Window

    プロジェクト上で Lint を実行するために、パッケージエクスプローラからプロジェクトを選択し、Lint ツールバーアクション（画像の左上）をクリックします。

    代わりの方法として、プロジェクト右クリックからAndroid Toolsのサブメニューから”Run Lint”を実行。これにより、Lint Windows が開かれてエラーが追加されます。エラーを選択すると、詳細説明が右のテキストエリアに表示されます。

    Lint View でエラーをダブルクリックするとソースファイルのエラーの箇所にジャンプします。それぞれの警告のアイコンは重要性を示しており、警告の修正方法（次のセクションで紹介）が小さな電球で表示されます。

    Windows にはアクションバーがあり（上部の右側の端の角）、以下のことをしてくれます。

    • lintを再実行して、結果を更新できます。（更新中の間、ストップボタンで中止もできます）
    • もし修正を無視したければ、エラーを修正済みにできます。
    • 警告のマーカーを削除します。
    • すべての警告マーカーを削除します。

    クイック修正

    多数の lint 警告は自動修正機能を持っています。たとえば、様々な layoutopt 修正項目は修正候補を出してくれます（例：wap_contentを 0dp に置き換える）

    • lint view から、電球をクリックして修正する
    • レイアウトエディタの警告から、Fixボタンを押して修正する
    • XMLソースエディタから、Quick Fix(Ctrl-1 or Command-1)を実行したり、警告に関連づけられている修正を選択する。
    エラーの抑止

    エディタの Quick Fix メニューから以下の選択ができます。

    • このファイル内のみ無視する
    • このプロジェクト内で無視する
    • ある期間、警告を無視する

    （もし quickfix 上の lint 修正アクションが見つからなければ、既知の不具合を見てください。）

    これらの選択肢は、プロジェクトの lint.xml に保存されており、コマンドラインツールによって見ることができます。
    このように、UI上から警告を無視することができ、ソースプロジェクトのlint.xml ファイルを確認し、lint実行時の他の項目も無視設定したものは、表示されなくなります。（たぶん、手動で検証したみた結果）

    オプション

    すべてのプロジェクトで利用されるオプションのlint 全体オプションを編集するには、通常のEclipse オプションのndroid > Lint Options を選択してください。

    すべてのプロジェクトで利用されるオプションのlint 全体オプションを編集するには、通常のEclipse オプションのndroid > Lint Options を選択してください。

    オプションの項目を選択した場合、右下のドロップダウンから Severity(厳密性）（訳者注釈：errorにするかwarningにするか）を設定できます。これによって正確に項目をエラーにするかどうかを設定できます。（例えば、ダイアログのトップ近くにあるAPK作成時に中止する。など）

    項目のチェックをオフにする場合は、severityで“Ignore”を選択してください。

    lint 設定をプロジェクト毎に編集しないように注意してください。プロジェクト設定ダイアログを開いて（プロジェクト上で右クリック）、Android Lint の設定ページを探してください。オプションダイアログで手動でSeverityを設定するとエラーを抑止すると共に lint.xml ファイルに記録されます。それから、チーム内の他の項目は、プロジェクト内で設定した同じものを利用できます。

    インストール方法

    いまわかっていることだけでいうと、ADT16に早くアクセスできるように計画しています。（訳者注：すでにADT16.0.1がリリースされています。）

    ソースコードが待ちきれないときは、git ソースコードリポジトリが sdk/lint フォルダーで利用できます。(手順は、
    http://source.android.com/source/downloading.html　をみてください。そして、マスターリポジトリからソースコードを取得してください。

    既知の不具合
    • この項目(21124)はADT16で修正済み。
    • 未使用のリソース：未使用のリソースの発見は、いくつかのリソースで利用されている場合に正しく動作しない場合があります。lintがコマンドラインから実行されたとき、リソース参照を探すため内に簡単な文字列分析を利用します。コメントや文字列リテラルなどを無視する間に、まだ切り替えが遅れるかもしれないためです。lintがeclipseで動作しているとき、より正しい結果になるようにパースツリーを利用します。このプランは、lintコアがどのようなところで実行したとしても正しく動作するようなフルパースに統合するためです。
    • Overdraw 検出：検出を利用していないような場合に、javaコードを分析する必要があり、現在主要なJavaパースツリーは動作していません。（リソース検出を利用していない場合と違って、eclipse 内で実行することはできます）

    Lint で解析対象になる項目

    次のエントリの「Android Lint 解析内容の詳細を調査」で紹介しているので参考にしてください。

    以上

    ]]>     http://andbrowser.com/development/knowhow/712/android-lint/feed/ 19     Android Development Tools(ADT) r16.0.1 更新情報 http://andbrowser.com/development/knowhow/697/adt-r16-0-1/ http://andbrowser.com/development/knowhow/697/adt-r16-0-1/#comments Sun, 18 Dec 2011 04:05:26 +0000 admin http://andbrowser.com/?p=697 Android ADT 16.0.1

    ADT16.0.1の意訳です。完璧な自信はありませんので原文も一緒にご参照ください。

    Android Development Tools(ADT) 16.0.1リリース

    adt r16.0.0 がリリースされてから１週間の時間が経たない間にadt r16.0.1 がリリースされました。r16.0.0リリース後に問題やユーザへの影響の大きい不具合修正がメインのようです。

    ADT 16.0.1 (2011年12月)

    依存関係：
    • ADT 16.0.1 を利用するためには、Eclipse Helios (Version 3.6) や それ以上のバージョンが必須。
    • ADT 16.0.1 は SDK Tools r16 を利用する前提で開発されています。もしまだ SDK Tools r16 をインストールしていない場合は、Android SDK Manager を利用してインストールしてください。
    不具合修正：
    • 9-patch は、いくつかのケースで通常のビットマップとしてパッケージされるようにビルドに関する項目を修正
    • Lintツールに関する項目を修正。
    • SDK Manager に関する項目を修正。
    ]]>     http://andbrowser.com/development/knowhow/697/adt-r16-0-1/feed/ 3     Android Development Tools(ADT) 16 更新情報 http://andbrowser.com/development/knowhow/693/android-adt-16/ http://andbrowser.com/development/knowhow/693/android-adt-16/#comments Fri, 16 Dec 2011 10:03:13 +0000 admin http://andbrowser.com/?p=693 ADT16.0.0の意訳です。完璧な自信はありませんので原文も一緒にご参照ください。

    ADT 16.0.0 (2011年12月)

    依存関係：
    • ADT 16.0.0 を利用するためには、Eclipse Helios (Version 3.6) や それ以上のバージョンが必須。
    • ADT 16.0.0 は SDK Tools r16 を利用する前提で開発されています。もしまだ SDK Tools r16 をインストールしていない場合は、Android SDK Manager を利用してインストールしてください。
    改良の概要：
    ]]>     http://andbrowser.com/development/knowhow/693/android-adt-16/feed/ 0     SDK Tools r16 更新情報 http://andbrowser.com/development/680/sdk-tools-r16/ http://andbrowser.com/development/680/sdk-tools-r16/#comments Thu, 15 Dec 2011 23:13:07 +0000 admin http://andbrowser.com/?p=680 SDK Tools, Revision 16の意訳です。完璧な自信はありませんので原文も一緒にご参照ください。

    SDK Tools, Revision 16 (2011年12月)

    重要なお知らせ： Android SDK Manager から新しいAndroid 4.0 のシステムコンポーネントをダウンロードするために、SDK Tools をバージョン14かそれ以上に更新して、Android SDK Manager を再起動すべきです。もしAndroid 4.0 システムコンポーネントをダウンロードしなければ、必要ありません。

    依存関係（利用上の前提条件）：
    • Android SDK Platform-tools がバージョン9かそれ以上
    • もしEclipse(ADTを含めて）を利用する場合、注意点があります。SDK Tools r16は ADT 16やそれ以上を利用するように設計されています。ADTプラグインをADT 16に更新することを強くお薦めします。
    • もしEclipse以外で開発する場合、 Apache Ant 1.8 かそれ以上を利用すべきです。
    概要：
    • Android プロジェクト (詳細情報)にエラーを発見するための Lint ツールが追加されます。（著者追加：Lintについてはこちら）

    • センサーエミュレーションサポートが追加。物理的Androidデバイスからセンサーデータを読むために（データを）エミュレータに付与します。
    • Mac OS X 上でカメラをエミュレートするためにウェブカメラを利用可能なサポートを追加
    不具合修正：
    ]]>     http://andbrowser.com/development/680/sdk-tools-r16/feed/ 2     Android Development Tools(ADT)15 更新内容 http://andbrowser.com/development/knowhow/543/android-adt15-update-info/ http://andbrowser.com/development/knowhow/543/android-adt15-update-info/#comments Sat, 29 Oct 2011 03:50:17 +0000 admin http://andbrowser.com/?p=543 ADT14が出てからまだ1か月も立っていない間にADT15ができました。
    以下のサイトによると変更点はこのようなものだそうです。
    http://www.androidpolice.com/2011/10/27/for-developers-android-sdk-tools-r15-and-adt-15-bug-fixers-now-available/

    不具合修正

    ADT 15への修正
    • API レベルを11から13に指定しているプロジェクト内で Renderscript を利用しているときのビルド項目を修正 (Issue 21006).
    • 既に存在するソースコードからプロジェクトを作成したときの不具合を修正
    • SDK Manager 内の不具合を修正 (Issue 20939, Issue 20607).
    • DDMS内の新しいLogcatパネルの中でスクロール中の不具合を修正
    SDK Tools r15への修正
    依存関係
    • Android SDK Platform-tools revision 9 以上が必要
    • eclipse と ADT で開発する場合は、ADT15以上が必要です。ADT 15 以上に更新することを強くお勧めします。.
    • eclipse 以外で開発する場合は、ant 1.8 以上が必須です。
    不具合修正
    • Webカメラ検出・追加に伴う Linux 上でのエミュレータの停止問題を修正(Issue 20952)
    • エミュレータ起動時の -wipe-data オプション指定時の不具合を修正
    • API レベルを11から13に指定しているプロジェクト内で Renderscript を利用しているときのビルド項目を修正 (Issue 21006)
    • GoogleTV add-on を利用時の AVD 作成時の不具合を修正(Issue 20963)
    • ant テストに関する不具合修正(Issue 20979)
    • andoirdコマンドの update project に関する不具合修正(Issue 20535)
    • DDMS内の新しいLogcatパネルの中でスクロール中の不具合を修正
    • MonkeyRunner に関する不具合修正(Issue 20964)
    • SDK Manager に関する不具合修正(Issue 20939, Issue 20607)

    ADTはバージョンアップするごとに使いやすさが増していっているのでこれからの進化が楽しみです。

    ]]>     http://andbrowser.com/development/knowhow/543/android-adt15-update-info/feed/ 3     Androidアプリ開発向け Eclipse XML Formatter http://andbrowser.com/development/knowhow/413/android-eclipse-xml-formatter/ http://andbrowser.com/development/knowhow/413/android-eclipse-xml-formatter/#comments Sun, 11 Sep 2011 05:23:36 +0000 admin http://andbrowser.com/?p=413

    Androidアプリ開発でもっとも多く利用されている IDE は eclipse で、eclipse の便利な機能としてソースコードを整形（インデント位置やif前後のスペースや{}括りの位置、改行位置など）機能があります。詳しくは[Eclipse] ソースコード整形（Code Format / Java Code Style Formatter）にも説明があります。

    XMLのソースコード整形の問題点

    上記のeclipseのjavaソースコード整形は大変便利なのですが、Androidアプリ開発でＵＩを作成する場合に利用するXMLファイルには同じ整形ルールが効きません。

    以下のようにXMLファイル上でマウス右クリック→「Source」→「Format」（キーボードショートカットの場合、Shift+Ctrl+f）を実行しても、以下のような結果となり1行に１つや2つのアトリビュートが入ったものとなり、見づらかったり、１アトリビュート削除や切り取り貼り付けが実施しづらいものになります。

    EclipseXmlSourceFormat

    XMLフォーマッターの標準設定の場合

    具体的には以下のように1行に２つの要素（アトリビュート）が入るため、切り貼りや削除がやりにくい状態です。

    XMLのソースコード整形ルールの設定

    上記の問題は解決可能です。eclipse で XML ファイルのコード整形を実施する場合は、javaソースコードへの設定とは別に設定を行う必要があります。
    設定場所は、メニューの[Window]→[Preference]でPreferenceを開いて、以下のキャプチャ画像のように[XML]→[XML Files]→[Editor]に存在します。

    Eclipse XML Format Setting

    • Split multiple attriutes each on a new line
      • 複数の属性をそれぞ新規行に分割
    • Align final bracket in multi-line element tags
      • 複数行要素タグに最終括弧を位置合わせ

    (pleadesの翻訳参照)

    「複数の属性をそれぞ新規行に分割」を設定ＯＮにした場合

    「複数の属性をそれぞ新規行に分割」と「複数行要素タグに最終括弧を位置合わせ」を設定ＯＮにした場合

    2つの設定の比較

    ２つの設定を抜粋して以下のように比較してみると、閉じるブラケット（>）の位置や閉じるタグ（）の位置が異なります。

    切り貼りを行うことを考えると、両方ともＯＮの設定がおススメです。

    結論

    Androidアプリ開発を行う場合、XML で UI を記載します。。画面数や機能が多くなってくるとこのレイアウトＸＭＬの数も増えていくと思います。そうなると、ＸＭＬ内での切り貼りや他のアプリに利用するためにレイアウトＸＭＬの一部だけを再利用したり、コピペで持っていきたいという場合が増えてくると思います。それ以外にも git や svn のような構成管理システムを利用している場合、システムに変更点を入力するまえに diff で確認するときに1行ごとに変更点が見えることは大変有益です。個人的にはこちらの効果のほうが協力だと思っています。XML Formatter の実行方法は、マウス右クリックからの 

    [/source]

    ->[Format]もよいのですが、キーボードショートカットのShift+Ctrl+f が簡単でよいと思います。残念ながらJava エディターの Formatter のように save action に xml formatter の機能を付けることがいまの eclipse ではできない（？）ようなので、XMLを書き変えたら、XMLで何か編集したら、Shift+Ctrl+f を押す癖をつけておくとよいです。もし、eclipseで XML Formatter を保存時に適用する方法があれば教えてください。標準設定のままのＸＭＬ Formatter では、相当な手間が発生するため、今回ご紹介した２つの設定は、常にＯＮにしておくことをお勧めします。

    おまけ

    今回の設定項目の4つ目の「Clear all blank lines」については、一人で開発する場合はON,OFFどちらでもいいと思いますが、複数人で開発する場合は、ONにして全体のＸＭＬで統一できるようにしておいたほうが個人的にはよいと思います。

    ]]>     http://andbrowser.com/development/knowhow/413/android-eclipse-xml-formatter/feed/ 15     メモリリークを発見！Androidアプリのメモリ解析手法　その２ OQL (Object Query Language)利用方法 http://andbrowser.com/development/knowhow/289/eclipse-android-memory-leak-mat-oql/ http://andbrowser.com/development/knowhow/289/eclipse-android-memory-leak-mat-oql/#comments Thu, 18 Aug 2011 10:22:38 +0000 admin http://andbrowser.com/?p=289 Eclipse Memory Analyzer (MAT)のサイト画像

    「メモリリークを発見！Androidアプリのメモリ解析手法」でEclipse Memory Analyzer(MAT)のインストール方法と使い方の紹介をしました。今回は、Eclipse Memory Analyzer (MAT)のさらに踏み込んだ使い方を紹介します。

    Eclipse Memory Analyzer(MAT)のインストール方法

    MATがまだインストールしていない場合は、以下の手順でインストールしてください。

    • Eclipseのメニューバーの（日本語化済みの場合）「ヘルプ」⇒「新規ソフトウェアのインストール」
      • 作業対象：–すべての使用可能なサイト–
      • フィルター入力：memory
      Memory Analyzer (MAT)インストール画面

      Memory Analyzer (MAT)インストール画面

    • 「Memory Analyzer」 と 「Memory Analyzer(Charts)[オプション]」にチェックをいれて、「次へ」を選択し、インストールを継続
    • まだ再起動せずに、続いて、 「Memory Analyzer(Charts)[オプション]」で利用する図作成ライブラリ（BIRT)をインストール。これをいれておくとメモリ利用状況がMAT上で綺麗な図で表示されます。是非インストールしておきましょう。
      Memory Analyzer Charts向け図作成ライブラリBIRTインストール

      Memory Analyzer Charts向け図作成ライブラリBIRTインストール

    • インストール後は、eclipse 再起動を求められるので、再起動しましょう。

    OQL (Object Query Language)利用方法

    Eclipse Memory Analyzer(MAT)には、以下の主要な機能があり、OQLはクラスオブジェクトの任意の抽出方法を定義でできるものです。

    • アクション
      • ヒストグラム(Histgram)：クラスごとのインスタンス数を表示
      • クラスオブジェクトごとの木構造(Dominator Tree)：もっとも大きなクラスとそれらの存在期間を表示
      • 上位の消費者(Top Consumers)：クラスごととパッケージごとにもっともメモリを利用しているクラスを表示
      • クラスの複製(Duplicate Classes)：複数のクラスローダからロードされているクラスを発見（レビューコメント頂いたkare様、ありがとうございました）
    • レポート
      • メモリリーク予想(Leak Suspects)：メモリリークの予想とシステム概要をレポート
      • 上位のコンポーネント(Leak Suspects)：全体のヒープの1%よりも大きなコンポーネントをレポートする機能

      OQL (Object Query Language):は、Javaヒープの検索をするために利用できるＳＱＬのような問い合わせ言語です。OQLはJAVAヒープから必要な情報を選択したり、フィルターしたりすることができます。ＯＱＬは、JavaScrip埋め込み型言語（JavaScript Expression Language)をベースとしています。OQLのクエリー定義は以下のようなものです。

      select <JavaScript expression to select>
   [ from [instanceof] <class name> <identifier>
   [ where <JavaScript boolean expression to filter> ] ]

      class name にはフルパスの Javaクラス名（例えば、 java.lang.String）を指定します。

      OQLは、以下のMATのメニューから選択できます。

      Eclipse Memory Analyzer(MAT) OQL選択画面

      Eclipse Memory Analyzer(MAT) OQL選択画面

      OQLは特定のクラスオブジェクト検索を行えるものです。具体例として、100文字以上のString を保持しているオブジェクトを検索したい場合は以下のようなSQLに近いコマンドを実行します。OQLのテキストボックスに以下のコマンドを記載し、「！」ボタンをクリックすると実行されます。

      Eclipse Memory Analyzer(MAT) OQL実行方法

      Eclipse Memory Analyzer(MAT) OQL実行方法

      SELECT s FROM java.lang.String s WHERE (s.count >= 100)

      実行結果は以下のようになります。

      Eclipse Memory Analyzer(MAT)のOQL実行結果

      Eclipse Memory Analyzer(MAT)のOQL実行結果

      さらに、以下のようなクラスオブジェクトの中身の値も表示することができます。以下の例は、Fileオブジェクトの持っている path フィールドの中身の値を一覧で表示する例です。

      select file.path.value.toString() from java.io.File file

      実行結果は以下のようになります。

      Eclipse Memory Analyzer(MAT) OQL実行例 Fileオブジェクトのpathを表示

      Eclipse Memory Analyzer(MAT) OQL実行例 Fileオブジェクトのpathを表示

      SELECT cl FROM INSTANCEOF java.lang.ClassLoader cl

      実行結果は以下のようになります。

      Eclipse Memory Analyzer(MAT) OQL実行結果

      Eclipse Memory Analyzer(MAT) OQL実行結果

      プリミティブ配列を利用する場合は以下のように利用します。

      select a from int[] a where a.length >= 256

      Android的なOQLの利用方法

      Android開発でOQLを利用する方法としては、まだ良いものは思いついていませんが１つ紹介します。

      以下の例は、Activity を継承したクラスの一覧を表示するOQLです。いくつかの画面遷移を行うアプリの場合、ライフサイクルの管理をきちんと行っている前提で、画面遷移した直後やメモリを消費する処理を行った場合にヒープダンプを保存しておいて、後から以下のコメントでどのＡｃｔｉｖｉｔｙが残っているかを調査するのに役立ちます。

      SELECT ac FROM INSTANCEOF android.app.Activity ac

      Eclipse Memory Analyzer (MAT) OQL for Activity

      今回のテストで利用したソースは以下です。ボタンを押すと、ActivityContextActivity⇒ActivityContext2Activity⇒ActivityContext3Activity ⇒ActivityContext4Activity の順番にActivityを立ち上げていくのみのサンプルで、ActivityContext4Activityまで画面遷移してから実行した結果です。

      public class ActivityContextActivity extends Activity {

    /** Called when the activity is first created. */
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);
    }

    public void onClickButton(View v) {
        Intent intent = new Intent(this, ActivityContext2Activity.class);
        startActivity(intent);
    }
}

      OQLを利用してみた感想

      javaの世界では一般的な本ツールも、Androidの世界ではまだ Memory Analyzer ですら利用されていない状況ですが、Eclipse を利用したAndroid開発を進めていくうえで、Eclipse で提供されている JAVA テクノロジーには大変良いものが多く、是非活用していきたいと思っています。OQL以外にもまだまだ利用できるものがありそうなので調べていきたいと思います。

      Android開発でMemory Analyzer やOQLの便利使い方をご存じの方は是非コメント頂ければうれしいです。

      ]]> http://andbrowser.com/development/knowhow/289/eclipse-android-memory-leak-mat-oql/feed/ 17 メモリリークを発見！Androidアプリのメモリ解析手法 http://andbrowser.com/development/knowhow/65/eclipse-android-memory-leak-mat/ http://andbrowser.com/development/knowhow/65/eclipse-android-memory-leak-mat/#comments Sun, 03 Apr 2011 04:50:19 +0000 admin http://andbrowser.com/?p=65

      googleのAndroid開発者向け ブログに「Memory Analysis for Android Applications」という記事があったため、自分のために訳しました。参考になれば幸いです。本エントリを見るうえで、eclipse の基本的な使い方を理解している必要があります。

      Androidアプリのメモリ解析手法

      Dalvikランタイムは、ガベージコレクトしてくれるかもしれませんが、それはメモリ管理を行わなくてもよいというわけではありません。モバイル端末上でのメモリ利用状況は特に注意を払わなければなりません。本投稿では、開発するアプリのメモリ利用状況の把握を支援する Android SDK で提供しているメモリプロファイリングツール群のいくつかを紹介させて頂きます。

      メモリ利用時の問題はいくつか明らかになっています。例えば、もしあなたのアプリがユーザの画面タッチ操作のたびにメモリリークするとすると、最終的には OutOfMemoryError のきっかけになる可能性が高いでしょう。他の問題はもっと複雑で、（あなたのアプリがガベージコレクトが頻繁に発生し、かつ長い時間発生すると）そのアプリと全体のシステムの両方のパフォーマンスを下げる原因になるかもしれません。

      解析・分析のためのツール

      Android SDK はアプリのメモリ利用状況をプロファイリングする手法として、2つの方法を提供します。DDMSの”Allocation Tracker”タブとヒープダンプです(heap dums)。Allocation Tracker は、与えられた時間間隔の中で発生しているメモリ割り当ての種類を知りたいときに便利です。Allocation Trackerについてもっと情報が必要な場合は、Tracking Memory Allocations を見てください。
      しかし、それらはアプリケーションヒープの概要の状態に関する情報しか提供されません。本投稿の趣旨は、より強力なメモリ解析・分析のツールであるヒープの表示（dump）にフォーカスをあてていく予定です。

      ヒープダンプは、HPROF と言われているバイナリフォーマットの形式で保存されるスナップショット（ある瞬間の情報（点としての情報））です。Dalvik は似たようなフォーマットを利用しますが、java の HPROF Toolとまったく同じではありません。実行中のAndroidアプリのヒープダンプを生成するいくつかの方法があります。１つは DDMS の HPROF ファイルに保存する機能です。もし、あなたがもっと正確にダンプを作成したいときはandroid.os.Debug.dumpHprofData() メソッドを利用してプログラム上からヒープダンプを作成することもできます。

      ヒープダンプを解析するために、jhatやEclipse Memory Analyzer (MAT)のような一般的なツールも利用できます。
      しなしながら、最初に .hprof(拡張子）ファイルを Dalvik フォーマットから J2SE HPROF フォーマットに変換する必要がでてきます。
      そのためにAndroid SDK の中で提供されている hprof-conv ツールを利用できます。

      たとえば、

      hprof-conv dump.hprof converted-dump.hprof

      というコマンドで実行できます。

      例：メモリリークをデバッグする

      Dalvikランタイムの中で、プログラマは明示的にフリーなメモリを割り当てることはできません、そのため　C や C++ の言語のように本当にメモリがリークしているかどうかを知ることができません。

      ソースコード上にある”メモリリーク”は、不必要に長い間オブジェクトを参照し続けた場合に発生します。たまに 単一参照（single reference)は、大きな（大量な）オブジェクト群のガベージコレクタの実行を妨げることができます。

      Android SDKの中にある Honeycomb の Gallary Sample アプリを利用して、実例を用いて理解していきましょう。これは新しいHoneycomb API群のいくつかの使い方を知るためのシンプルな写真閲覧アプリです。

      ビルド方法とサンプルコードのダウンロード方法は、手順書(Android 開発者サイトのサンプルの取得方法）をご覧ください。

      どのようにデバッグできるかの手法を紹介するためにこのアプリに故意にメモリリークを追加しました。


      ネットワーク上から画像を取得するために、このアプリを修正したいと考えてみてください。よりレスポンスをよくするために、最近閲覧した画像を保持するキャッシュの実装を決めたとします。 ContentFragmen.java ファイルにいくつかの小さな変更を行ってみましょう。クラスの上部に新しいスタティック変数を追加しましょう。

      private static HashMap<String,Bitmap> sBitmapCache = new HashMap<String,Bitmap>();

      これは、ネットワークからロードするビットマップ群のキャッシュです。続いて updateContentAndRecycleBitmap() メソッドをネットワークからロードする前にキャッシュに存在するかどうかの確認を行うために変更し、ロード後にキャッシュにビットマップを追加します。

          void updateContentAndRecycleBitmap(int category, int position) {
        if (mCurrentActionMode != null) {
            mCurrentActionMode.finish();
        }

        // 描画するためのビットマップを取得し、ImageViewを更新

        // キャッシュにビットマップが存在するかどうかを確認
        String bitmapId = "" + category + "." + position;
        mBitmap = sBitmapCache.get(bitmapId);

        if (mBitmap == null) {
            // キャッシュにない場合、ビットマップをロードし、キャッシュに追加
            // 危険・注意！ 常にビットマップを削除することなしにキャッシュにアイテムを追加
            mBitmap = Directory.getCategory(category).getEntry(position)
                .getBitmap(getResources());
            sBitmapCache.put(bitmapId, mBitmap);
        }
        ((ImageView) getView().findViewById(R.id.image)).setImageBitmap(mBitmap);
    }

      私はここで故意にいれたメモリリークを紹介します。常にキャッシュを削除することなしに ビットマップをキャッシュに追加します。実際にアプリでこのような実装する場合は、いくつかの方法でキャッシュサイズに制限をかけたいを考えるでしょう。

      DDMSを利用してヒープの利用状況を確認

      Dalvik Debug Monitor Server (DDMS) は、主要なAndroidデバッグツールの１つです。DDMSは ADT Eclupse プラグインの一部で、単体動作版はAndroid SDKの tools/ ディレクトリの中にあります。DDMSに関する情報をもっと知りたい場合は、DDMSを利用してみましょう。

      それでは、このアプリのヒープ利用状況を確認するためにDDMSを利用しましょう。DDMSを起動する方法は2つあり、そのどちらでも起動できます。

      • Eclipse上からメニューバーを以下の順序で選択する方法

      Windows > Open Perspective > Other … > DDMS

      • コマンドライン上から tools/ ディレクトリの中にある ddms を起動する。

      （追記：Windowsの場合は、ddms.bat が起動され、Mac/Linux の場合は、ddmsが起動される。（それぞれに PATH を通している必要があります））

      左のパネルからcom.example.android.hcgalleryプロセスを選択して、ツールバー上の”Show heap updates”ボタンをクリックします。
      それから DDMS の VM Heap タブに切り替えます。

      ヒープメモリ利用状況について GC毎に更新されるいくつかの基本情報が見れます。最初の更新を行うために、”Cause GC”ボタンをクリックします。

      我々は live setという（割り当てメモリ列）8MBを少し超えるものをみることができます。サンプルアプリの写真をフリックすると、数字が増加していくのが見れます。このアプリは13枚の写真しかありませんが、リークしたメモリの容量が割り当てられていきます。このような場合リークの最悪のパターンが訪れます。しかしながら我々は決して リークすることにより OutOfMemoryError を起こしてはいけません。

      ヒープダンプ(heap dumps)を作成

      問題を追うためにヒープダンプを作ってみましょう。DDMSツールバーのDump HPRPF fileボタンをクリックして、保存場所を選択して、それから hprof-conv でコンバートしてください。この例では、MAT(Ver 1.0.1)のスタンドアローンバージョン(Stand alone version)を利用しています。これはMATダウンロードサイトで提供されています。

      もし、ADT(DDMSのプラグインの親元)が実行している場合や Eclipse に MAT がインストールされている場合は、”dump HPROF”ボタンを押すと自動的にコンバート（hprof-convを実行）してくれ、Eclipse内（MATでオープンされる）で変換された hprof ファイルを開いてくれます。

      MATを利用したヒープダンプの解析・分析

      MATを実行し、いま先ほど作成したコンバート済みの HPROF ファイルをロードしてください。（上記のように必要なツールがインストールされていれば、自動的にコンバートとMAT起動を行ってくれます）。MATは強力なツールですべての機能を説明するためには本投稿の範囲を超えてしまいます。そのためいまはリークを発見するために利用する１つの方法として、Histogram View（ヒストグラムビュー）を紹介します。ヒストグラムビューはインスタンスの数でソートされたクラスのリストと表面上のヒープ（表層ヒープ：shallow heap）（すべてのインスタンスで利用しているメモリの総合計）と保持されたヒープ（保持ヒープ：retained heap）（他のオブジェクトへの参照をもっているオブジェクトを含めたすべてのインスタンスで生きているメモリの総合計）を表示します。

      もし shallow heap でソートすれば、byte配列のインスタンスが上部に表示されます。Android 3.0(ハニカム）の場合、ビットマップオブジェクトのピクセルデータは byte配列に保存されます。（以前は Dalvik heap に保存されませんでした）
      そして、それらのオブジェクトのサイズを参考にして、メモリリークしたビットマップのための裏にあるメモリだと賭けても(bet)あっている(safe)でしょう。

      byte[] クラス上で右クリックで押して、
      List Objects → incoming references
      を選択します。これは、ヒープの中に byte 配列のすべてをリストで表示したもので、Shallow Heapの利用状況をベースにソートすることのできます。

      大きなオブジェクトの一つを選び、ドリルダウンしていきましょう。これは、オブジェクトのrootからの path を見せてくれます。生存しているオブジェクト参照のつながりを表しています。ほら、我々のビットマップキャッシュがありますね。

      MATはこれがリークかどうかを教えてはくれません。なぜなら、それが必要なものか、そうでないかがわからないためです。それはプログラマのみができることなのです。今回の場合、キャッシュは比較的アプリの休憩中（ユーザが操作していない場合）にメモリの大きな容量を使っています。そのためキャッシュのサイズの上限を検討しないといけません。

      MATでヒープダンプを比較

      メモリリークをデバッグしているとき、2つの異なったポイントのヒープ利用状況を比較すると、とても有益です。それを行うために、2つの異なる HPRPOF ファイルを作成する必要があります。（hprof-convを使ってコンバートは忘れずに！）

      では、ここでどうやって MAT で2つのヒープダンプを比較すればよいかをお伝えします。（少し重ねればよいのです）

      1. 最初のHPROFファイルを開く（Fie > Open Heap Dump)
      2. ヒストグラムビュー(Histogram view)を開く
      3. Navigation History view（eclipe のメニューのWindow > Navigation History。なければ Window > Other… > Memory Analyzer Views < Navigation Historyで選択）の中の histogram を選択し、右クリックして「Add to Compare Basket」を選ぶ
      4. 2つ目の HPROF ファイルをステップ2と3を繰り返してください
      5. 「Compare Basket view」に切り替えて、Compare the Results（Compare Basket viewの上部の右上にある赤い！アイコン）をクリック

      結論

      本投稿ではどのように allocation Tracker と ヒープダンプ(heap dumps)はアプリのメモリ利用状況のよりより見え方・感じ方を得るための方法を紹介しました。私はまた どのよに Eclipse Memory Analyzer(MAT) がアプリのメモリリークを追う方法を紹介しました。MATは強力なツールであり、私もこのツールで何ができるかの表面しか紹介しませんでした。

      もしあなたがよりもっと学びたいとお考えなら、以下のURLのいくつかを読むことをお勧めします。

      メモリリークを避けるためにお薦め本

      Effective Java 第2版

      まだお持ちでないなら、メモリリークを避けるためにも必読です。
      増補改訂版Java言語で学ぶデザインパターン入門

      先人の知恵であるパターンを利用することによって大幅にメモリリークを避けられるようになります。
      増補改訂版 Java言語で学ぶデザインパターン入門 マルチスレッド編

      マルチスレッド環境ではメモリリークが発生しやすくなります。マルチスレッドを扱う場合は必読です。


      ]]>       http://andbrowser.com/development/knowhow/65/eclipse-android-memory-leak-mat/feed/ 120