ラベル android studio の投稿を表示しています。 すべての投稿を表示
ラベル android studio の投稿を表示しています。 すべての投稿を表示

2023年6月20日火曜日

Google Drive api v3で例外発生

久しぶりに、はまりました。自分でも忘れないように残しておきます。


機能の更新のついでにSDKを33に、gradle-wrapper.propetiesを8.0に上げて、リリース前に念のため、releaseモードで動かしてみたら、Google Drive api V3を使用したバックアップと復元がエラーとなってしまうことに気付きました。

例外の内容は以下です。

com.google.api.client.googleapis.json.GoogleJsonResponseException: 403 Forbidden
{
  "code" : 403,
  "errors" : [ {
    "domain" : "global",
    "message" : "The request is missing a valid API key.",
    "reason" : "forbidden"
  } ],
  "message" : "The request is missing a valid API key.",
  "status" : "PERMISSION_DENIED"
}

API keyなんていままで使っていなかったので、この例外の意味は分かりませんでした。

しかし、releaseモードだけでおかしくなるのは、大抵は、難読化が原因です。


結論から書くと、proguard-rules.proに以下を追加すれば、正常に動作します。
-keep class com.google.api.services.drive.** {*;}
-keep class com.google.api.client.http.HttpHeaders {*;}



1行目は以前から記述していたのですが、今回2行目を追加しました。ここに行きつくのは結構大変でした。

まずは、世界中の誰かが解決していれば楽なので、ネット検索したのですが、見つかりませんでした。

例外の内容に従って、API keyを作成して、設定してみましたが、新たな例外になってしまいました。

あるいは、drive.files.list()等の実行時にトークンが消えているようなので、drive.files.list()実行時にトークンを渡してみると動くが、ダウンロードを行う以下の部分が違うエラーになってしまいました。
drive.files().get(fileId).executeMediaAndDownloadTo()

その他にも四苦八苦したのですが埒が明かないので、大変面倒くさいですが、debugモードとreleaseモードでデバッグをして、ライブラリ内の変数の中身を比較することにしました。
releaseモードでのデバッグは、appのbuild.gradleのbuildTypesのreleaseに以下を追加でできます。

buildTypes {
    release {
        :
        debuggable true
        :
    }
}

そして、com.google.api.client.http.HttpHeaders関連がreleaseモードでは、空になっている部分があり、そのせいで、トークンが消えていたことが分かりました。
proguard-rules.proに前述のkeepの行を追加して動かすと、バックアップも復元も全て正常に動作しました。

以上です。


2022年9月30日金曜日

しつこい「android.os.TransactionTooLargeException」

こんにちは。



結構前から掲題の例外「android.os.TransactionTooLargeException: data parcel size 754884 bytes」が発生していて、何度も対応していたのですが、未だに稀に発生していました。

非常に稀なので、優先順位を下げていたのですが、再度本腰をあげて調査しました。



今までも自分で再現できたことが無かったのですが、まずは再現させることから取り掛かりました。

これの例外は、画面の回転、画面がバックスタックに移動、ViewPagerでスクロールなどで、画面の状態を保持する際に、データサイズが上限を超えたときに起きるようです。

ただし、上限は1MBらしいですが、1MB以下でも例外が発生しています。

状態保持は、ActivityやFragmentの「onSaveInstanceState(Bundle)」で行い、「onCreate(Bundle)」などのBundleを使って復元します。


そこで、1MB以上保持するように計算して、テストデータ作成と画面操作(スクロール&バックスタック)をしますが、例外は発生しません。

ここで、Android StudioのProfilerでMemoryのCapture heap dumpを取ってみます。

一覧の「Fragment$SavedState」をみると「Retained Size」が確かに1MB超えています。



そこで、前述の操作はDebugモードで行っていたので、Releaseモードで全く同じ操作をしてみたところ、例外発生しました。

この例外は、Debugモードでは発生しないと推測しました。あくまで推測ですが。



そして修正を施して、Releaseモードでテストを行って、例外が発生しないことを確認しました。

修正した内容は、ViewPagerを使った画面でEditTextを複数配置していて、EditTextの状態保持は既存の処理に任せていたのを自前で行うことに変更しました。

EditTextのプロパティに「android:saveEnabled="false"」を追加して、既存の処理は止めました。



これで様子見です。


以上です。


2022年9月29日木曜日

実行中の通知が表示されない

こんにちは。


Android12の動作の変更点の見逃していた部分を書いておきます。


自分が作ったアプリをAndroid12で操作していると実行中の通知が表示されないのが気になっていました。

実行中の後の完了の通知は表示されるので、緊急性はないかと後回しにしていました。


しかし、新しいアプリをリリースするにあたって、再度、Android12の動作の変更点をじっくり読み返して、やっと気づきました。


「フォアグラウンド サービス通知の UX の遅延」のせいでした。

「短時間実行されるフォアグラウンド サービスのエクスペリエンスを簡素化するため、Android 12 以降を実行するデバイスでは、特定のフォアグラウンド サービスについて、フォアグラウンド サービス通知の表示を 10 秒間遅らせることができます(少数の例外があります)。この変更により、通知が表示される前に存続時間の短いタスクを完了する機会が与えられます。」


10秒も遅らせると!!

実行を通知する必要がなく、ちょっとした処理であれば、いちいち通知しないのはよいでしょうが、自分のアプリの場合は実行しているのか分からないのは困ります。


すぐに通知を表示させる方法は簡単で、以下のコメントの次の行を追加するだけです。



よかったら、アプリの上に表示できるメモ

フローティングメモ - Google Play のアプリ

をよろしくお願いします。


以上です。






 

2019年7月16日火曜日

app bundleにすると、FabricのCrashlyticsで難読化されたままになる。

こんにちは。

Androidのapkについてです。

Androidアプリは、各ネイティブプラットフォームの7個のApkを作成してリリースしていたのですが、Google側で各Apkを作成してくれるという、app bundleというものが登場しました。

いままでは、7個のMappingファイルを手動でアップロードしたりと、リリースに手間が掛かっていました。

しかし、app bundleにすれば、Mappingファイルは一個で済み、しかも自動でアップロードしてくれるようになります。

ようやく最近、app bundleに変更したのですが、しばらく経ってから異変に気付きました。

FabricのCrashlyticsに上がってくるエラーのファンクション名や行番号が難読化されたままになっているのです。

これでは、どこでエラーが発生しているのか分かりません。



FabricのGradleのリリースノートを見てみると、1.26.0に「Added mapping file upload support to Android App Bundle builds.」とありました。

↓こちらを参照ください。
https://docs.fabric.io/android/changelog.html#fabric-gradle-plugin

最新のバージョンに変更して、リリースしたところ、FabricのCrashlyticsの難読化は外れました。

ちなみに、他のライブラリは古いバージョンだと警告が出るのですが、Fabricは出ませんでした。

そのため、最新にしていませんでした。

注意が必要ですね。

2019年1月18日金曜日

ブレイクポイントで止まらずデバッグできない。

明けましておめでとうございます。

早速ですが、Android Studioについて書きます。

今月、2019年1月にAndroid Gradle plugin 3.3.0がリリースされました。

https://developer.android.com/studio/releases/gradle-plugin

これまでもリリースされるたびに何かしらうまくいかなくなり、対応に結構な時間を取られます。

今回は、デバッグができなくなりました・・・。

ブレイクポイントで止まらなくなったのです。

なんとか今はデバッグできるようになったので、記事に残しておきます。

まず、私のGradleは、以下のようにしていました。



上記のようにデバッグも「minifyEnabled true」としていたのは、メソッド数が64Kを越えてしまうためでした。

参考にしたページが以下です。


https://developer.android.com/studio/build/shrink-code?hl=ja

この中の「未使用のコードを削除する」をやって、デバッグでもメソッド数を減らしていたわけです。

去年まではこれでデバッグが出来ていました。

しかし、2019年はダメでした。

色々試した結果、今は、以下のようにしています。


「minifyEnabled false」とします。すると当然64Kエラーとなります。そこで、Multidexを採用します。

Multidexについては、以下に書いてあります。

https://developer.android.com/studio/build/multidex?hl=ja



しかも、今回、次のような一文を見つけました。「コードを圧縮すると、ビルド時間が長くなることに注意してください。」

・・・「minifyEnabled false」にした途端、ビルドがものすごく速くなりました。

それと、今まで、Instant Runでデバッグすると、スマホが強制再起動になっていたため、Instant Runをオフにしてましたが、上記対応後、Instant Runにしても、今のところ、一度も強制再起動になっていません。

最初から、Multidexにしていればよかったです・・・。

ということで、2019年もデバッグしまくります。


以上です。

2018年12月18日火曜日

Google Driveに接続できない

こんにちは。

先日、新アプリをリリースしたのですが、実はリリースが予定より一週間弱延びてしまいました。

理由は、リリース版だとGoogle Driveにバックアップが出来なかったためです。

バックアップ機能は、ライブラリ化しており、他のアプリと共通です。

他のアプリで問題なく動いているので、GoogleのApi ManagerでGoogle DriveのApiの設定を行うのですが、同じように設定すれば動くはずでした。

そもそも、デバッグ版では動いていました。

しかし!!全く同じように設定しているのにアプリが停止してしまいます。

症状としては、ファイルリストを取得する際に、以下のfileList.getItems()がnullとなってしまいます。

まだアプリを公開していないからか、とか、色々悩みましたが、一旦、頭の中をリセットして考え直してみました。

そしたら、「あれ?まさか難読化のせいか?」と気づきました。

難読化するときには、使用する外部ライブラリのクラス名や関数名まで難読化してしまうと自分のプログラムからクラスや関数が見つけられなくなります。

そのため、「proguard-rules.pro」で名前をキープするクラスなどを設定します。

ただ、今までの経験では、「proguard-rules.pro」で設定が足りない場合は、リリースビルドが通りませんでした。

今回は、リリースビルドも問題なく通っていました。

まさかと思いながらも、ググってみると、「proguard-rules.pro」に設定の追加が必要だという記事がありました。

Driveのライブラリは「com.google.apis:google-api-services-drive:v2-rev170-1.20.0」です。

「proguard-rules.pro」の一部です。「追加」の下を今回追加しました。

これで、ビルドし直し、動かすと・・・あぁ・・・動きました・・・。

詳しく調べる時間がないですが、動いてよかったです。




2018年10月1日月曜日

再びEditTextのメモリリーク

こんにちは。

以前にもEditTextでメモリリークを発見し対応したのですが、その後のライブラリのアップデートで改善されていました。

参考記事:「メモリリーク その4 EditText」

しかし、再び、別の原因によるEditTextのメモリリークが発生しました。

メモリリークが発生する場合と発生しない場合があり、しばらく気付かなかったため、どのライブラリから発生するのかは分かりません。

前回と同様、LeakCanaryで発見しました。

端末:Xperia performance
OS:Android 8.0.0

LeakCanaryより↓
In com.bnbnapp.bookshelf:3.13:3064.
* com.bnbnapp.bookshelf.ConditionActivity has leaked:
* GC ROOT static android.view.accessibility.AccessibilityNodeInfo.sPool
* references android.util.Pools$SynchronizedPool.mPool
* references array java.lang.Object[].[32]
* references android.view.accessibility.AccessibilityNodeInfo.mOriginalText
* references android.text.method.ReplacementTransformationMethod$SpannedReplacementCharSequence.mSpanned
* references android.text.SpannableStringBuilder.mSpans
* references array java.lang.Object[].[0]
* references android.widget.TextView$ChangeWatcher.this$0
* references android.support.v7.widget.AppCompatEditText.mContext
* leaks com.bnbnapp.bookshelf.ConditionActivity instance
 
こちらの対応は以下。

上記対応すると以下のメモリリークを検出しました。

LeakCanaryより↓
In com.bnbnapp.bookshelf:3.13:3064.
* com.bnbnapp.bookshelf.ConditionActivity has leaked:
* GC ROOT static android.view.accessibility.AccessibilityNodeInfo.sPool
* references android.util.Pools$SynchronizedPool.mPool
* references array java.lang.Object[].[5]
* references android.view.accessibility.AccessibilityNodeInfo.mOriginalText
* references android.text.method.ReplacementTransformationMethod$SpannedReplacementCharSequence.mSpanned
* references android.text.SpannableStringBuilder.mFilters
* references array android.text.InputFilter[].[0]
* references android.widget.Editor$UndoInputFilter.mEditor
* references android.widget.Editor.mProcessTextIntentActionsHandler
* references android.widget.Editor$ProcessTextIntentActionsHandler.mContext
* leaks com.bnbnapp.bookshelf.ConditionActivity instance
 
こちらの対応は以下。

以上で、メモリリークは検出されなくなりました。

2018年6月9日土曜日

Style.xml内の「Theme」が赤字

おはようございます。

build toolsを3.1.0から上げると、Style.xml内の「Theme」が赤字になってしまいます。

Go To Declaration(Ctrl+B)で宣言部分に飛ぶことはできます。

なのに、たしか、「Cannot resolve symbol」となっているのです。

どうしても解決できず、保留にしていました。

現在、3.1.3まで上がっているにも関わらず、同じ現象になってしまいます。

もう、このままにしとくわけにはいかないため、再調査をして、ようやく解決しました。

方法は簡単です。

1.Android Studioのメニューの「File」-「Close Project」でプロジェクトを閉じます。

2.「Welcome to Android Studio」画面の「Import project」をクリックし、該当プロジェクトをインポートします。

これで、エラーが消えました。


Syncで「Failed to resolve: common」

おはようございます。

キャッシュをクリアしたところ、Syncでエラーとなるようになりました。


エラーの内容は、上の画像のように「Failed to resolve: common」と出るだけで、さっぱり分かりません。

「common」という自作ライブラリを使っていたので、自作ライブラリのせいかと思って調べていたのですが、どうも違います。

そして、ようやく判明しました。

Projectレベルのbuild.gradleは以下のようになっていました。

上記2か所の「jcenter()」と「google()」を逆にするとエラーが消えました。


理由は分かりません。こんなところで時間掛けられないので、理由までは調べません。

2018年5月22日火曜日

「Method '***' is too complex to analyze by data flow algorithm」

こんにちは。

久しぶりの更新です。

一通りコーディングが終わると、Android Studioのメニューの「Analyze」ー「Inspect Code」で、コードをチェックしています。

色々、チェックに引っかかった項目が出てくるのですが、初めて以下の項目が出ました。

「Method '***' is too complex to analyze by data flow algorithm」

'***'の部分は関数名です。

関数が複雑すぎると言われているみたいですが、しばらく原因が分からず放置していましたが、ようやく判明しました。

私の場合は、関数の行数が長すぎたようです。該当関数を二つに分けたところ、解消しました。


そもそも、関数は、コードの見やすさの観点からある程度の長さ以内になるようにしています。

ところが、この関数はエラー処理を後から何度も追加していったところ、長くなってしまいました。(コメント行を含め、238行もありました。)

複雑なアルゴリズムを組んでも、同じ警告が出るのかもしれませんが、行数が長くて警告する場合は、そう警告してもらいたいものです。

以上です。

2018年1月19日金曜日

メモリリーク その4 EditText

こんにちは。

現在までに発見したメモリリークの最終記事です。


compileSdkVersionを26に上げたところ、LeakCanaryでメモリリークを検出しました。

検出端末は、Xperia performanceです。

そのときのLeakCanaryのスクリーンショットが以下です。


LeakCanary

InputConnectionWrapperのmTargetが解放されないようです。

よって、上記が解放されるように対応しました。

まず、EditTextの代わりに自作のMyEditTextを用意しました。
次に、InputConnectionWrapperも自作し、closeConnectionでmTargetをnullにします。

以上により、メモリリークは検出されなくなりました。


2017年12月2日土曜日

logcatが表示されない!?デバッグでEditTextのあるActivity表示で落ちる!?


思いがけず、タブレットも開発に使用できるようになりました。

d tab(HUAWEIのd-01J)。

しばらくは、今まで通り、スマホで開発し、Releaseビルド後にタブレットで動作確認をしていました。

問題なく使えていたのですが、厄介なカメラ機能を修正したので、タブレットでデバッグを行ったところ、あるActivityに遷移すると落ちました。

logcatを見てみたら、エラーもデバッグログも出力されていません。

ここから、結構、はまりました。

とりあえず、logcatから解決方法を書きます。

HUAWEIは、Androidの隠しコマンドでログを出力するように設定する必要があるようです。(HUAWEI全機種なのかは、分かりません。)

電話アプリ、又は、標準の電卓アプリを使用します。持っているタブレットは電話機能がないので、電卓を使いました。

1)電話アプリの場合は、「*#*#2846579#*#*」
、電卓アプリの場合は、「()()2846579()()=」と入力します。

2)「ProjectMenu」という画面が起動しますので、「1.Background Settings」をクリックします。

3)「3.LOG Settings」をクリックします。

4)「AP Log」をチェックします。

これで、logcatが出力されるようになりました。

続いて、落ちる件について、ログが出力されるようになったので、調査開始です。


InputConnectionでキャストできないと出ているので、EditText付近だとは分かるのですが、EventProfiler.javaのソースをネットで探し出しても、330行目なんてありません。

しかし、このExceptionをネットで検索すると解決方法ありました。

https://stackoverflow.com/questions/47440771/focus-on-edittext-result-in-crash

このページにあるように、Android Studioのメニュー「Run」の 「Edit Configurations」をクリックし、左の「Android App - app」を選択して、右の「Profiling」の「Enable Advanced profiling」のチェックを外します。

これで、実行すると落ちなくなりました。

オフにした機能は以下に詳細が書かれています。

Measure App Performance with Android Profiler

Android Studio 3.0から追加された機能みたいです。

しかし、タブレットでカメラが落ちるので、まだまだかかりそうです・・・。


2017年10月31日火曜日

メモリリーク その3 AdMob広告の表示で

こんにちは。



AdMobの広告を表示させるために、AdMobの以下のガイドに沿ってソースを修正しました。

https://developers.google.com/admob/android/quick-start?hl=ja


ガイドより↓

しかし、これだとメモリリークを起こします。


以前にも書きましたが、ActivityのContextを渡し、そのContextを保持されてしまうとActivityを解放できません。

ApplicationContextを渡せば、Activityはメモリリークを起こしません。

また、MobileAds.initializeは、一回だけで良いと上記のガイドに記述があるので、ApplicationのonCreateで呼び出すようにしました。

なぜなら、MainActivityのonCreateは、一回だけ呼び出されるとは限りません。起動時以外にも、画面を回転させると呼び出されます。

以下のように修正しました。



以上です。


2017年10月12日木曜日

メモリリーク その2 AlertDialog

こんばんは。

今回もメモリリークについてです。

AlertDialogで、メモリリークが発生していました。

そもそも、使い方を誤っていました。

以下のようにすれば、簡単にメッセージダイアログが表示できますが、これではいけません。



画面を回転した場合などに、メモリリークが発生します。

Androidデベロッパーのページにも書かれていました。

https://developer.android.com/guide/topics/ui/dialogs.html?hl=ja

DialogFragmentを使ってダイアログを管理すると、ライフサイクルイベントが正しく処理されると書かれています。

個人のブログで、AlertDialogの使い方を見てコーディングしたのですが、ある程度コーディングした後に、上記のページを見つけました。

そして、実際にメモリリークするか調査してみると、しっかりとメモリリークしていました。

全てのAlertDialogを修正とテストするのは大変でした。

それから、ネットで検索する場合は、Androidデベロッパーのページや、リファレンスを最初に読むようにしています。

DialogFragmentを使ったAlertDialogのコーディング方法は、上記のページを参考にしてください。


2017年10月11日水曜日

メモリリーク その1

こんばんは。

忙しくて、なかなか更新できませんでした。

前回メモリリークを調査した結果、検出した内容です。

今回は、単純なコーディングミスです。

Staticな変数に、Contextを渡したクラスのインスタンスを保持しているのですが、ContextにActivityをキャストしたContextを渡していました。


ソースで説明します。


ToastクラスのインスタンスをContextを渡して作成し、Staticな変数で保持しています。
上記のshowToastを以下のように呼び出していたのです。


上記の例は、Activityで呼び出していたので、thisは、Activityです。

Contextは、ApplicationかActivityをと書かれていますので、以下のように変更したら、メモリリークはなくなりました。


Staticな変数は、要注意です。

2017年9月3日日曜日

メモリリーク調査


こんばんは。お久しぶりです。

ブログは更新していませんでしたが、開発は行っています。


ふと、メモリリークはしていないのか気になって、調査してみることにしました。

確保された領域は、どこからも参照されなくなれば、GC(ガベージコレクション)でシステムが勝手に解放してくれます。

参照をなくした後にGCを強制的に行い、解放が行われているかチェックすれば、メモリリークを見つけられます。


Android Studioでデバッグ中に、Android Monitorで、一連のチェックが行えます。




上のAndroid Monitorの赤で囲った部分の一番左のアイコンをクリックすると、GCが行われます。

真ん中のアイコンをクリックすると、メモリの状態が記録されます。


あるいは、Leakcanaryというライブラリを使用してもチェックできます。

Leakcanaryは、https://github.com/square/leakcanaryにあります。

やり方も記載されていますが、一点、はまったことがあります。

全く、メモリリークが検出されないのです。メモリリークが元々なかったのかと一瞬思いましたが、チェック自体が走った形跡もなかったので、ライブラリのソースを追ってみました。

なんと、デバッグでアタッチしている場合は、チェックしないようになっていました。

私、USBで繋いで、ばりばりデバッグアタッチしていました。

なので、スマホにデバッグ版をインストールした状態で、アイコンをタップしてアプリを単体で動かしたところ、メモリリークが無事?、検出されました。

Activityを閉じたときにチェックしています。


メモリリークの内容は、後日書こうと思います。

2017年4月5日水曜日

Unitテスト 変数の値検証

こんにちは。

今日は、Unitテストで、内部変数の値の検証の仕方を書きます。



まず、対象のActivityをモックとして定義します。


例えば、MainActivityのprivateなローカル変数「mPositionAll」に初期値を設定したい場合は、以下のようにします。


そして、変数の値を検証したい場合は、以下のようにします。


以上です。

2017年3月25日土曜日

難読化について

こんばんは。


JAVAの実行ファイルは、解読が容易です。

難読化することによって、解読が難しくなります。

変数名や関数名が、「a」とか「b」という簡単な名前に変わります。

難しくなるだけであって、解読できないわけではありません。

しかし、バレバレの状態よりも読みにくい状態にしておいて、損はないと思います。

また、変数名が短縮されるわけですから、容量が節約できます。

詳しくは、こちらを参照ください。



難読化の手順を簡単に記しておきます。


1.build.gradleを変更。



上記のようにminifyEnabledをtrueに変更し、proguardFileのパスを設定します。

私の場合は、「C:/Users/[UserName]/AppData/Local/Android/sdk/tools/proguard/proguard-android.txt」でした。


2.ビルドしてみて、エラーや警告に対応。


まず、sun.misc.Unsafeの警告が大量にでました。

以下のように、proguard-rules.proに追記します。



3.動かしてみて、エラーに対応。


releaseしか難読化できませんので、release版を実機などにインストールして、動かしてみます。

gsonのエラー、driveのエラー、zbarのエラー、adsのエラーに対応しました。

最終的に、以下のようになりました。



4.リリース後に、マッピングファイルもアップロードしておきます。


これについては、前述のこちらを参照ください。


以上です。

2017年3月24日金曜日

プレビューで色が取れない

こんばんは。

前回、「色も取れないらしく、colors.xmlに設定してある色ではなく、デフォルトの色で表示されてしまいます。」と書きましたが、再現してしまいました。


上記以外に、colors.xmlに設定してあるcolorを使用しているlayoutファイルを開くと、プレビューに以下のエラーが表示されます。



「Couldn't resolve resource @color/colorAnything」


実行すると、ちゃんと設定した色で表示されます。



色々調べた結果、以下で解決しました!!


1.「File」 -「Invalidate Caches / Restart...」をクリック。

2.表示されるメッセージ画面で、「Invalidate and Restart」をクリック。



キャッシュをクリアして、再起動するみたいです。

起動に、結構時間がかかりましたが、直りました。


2017年3月17日金曜日

layoutファイル名に大文字はダメ

こんにちは。

しょうもないエラーに引っかかってしまいました。恥ずかしい内容ですが、同じ過ちをしないようにするためにも、残しておきます。

ガリガリ、コーディングしていて、ふと、気づいたら、layoutファイルのプレビューで、エラーになってしまっていました。

styleが定義されていないというエラーだったと思います。
色も取れないらしく、colors.xmlに設定してある色ではなく、デフォルトの色で表示されてしまいます。

全然、原因が分からなく、時間だけが過ぎていきました。

ビルドすると、次のようなエラーが出ました。


'B' is not a valid file-based resource name character: File-based resource names must contain only lowercase a-z, 0-9, or underscore


英語は分かっているようで、分かっていませんでした。
指摘されたファイルの中で、大文字を使ってはいけないのかと勘違いしてしまいました。

原因は、layoutファイル名に、大文字を使っているからでした・・・。

原因が判明してから、改めて英文のエラーを読むと、なるほど、そう言ってる・・・。

以後、気を付けます。