Android 6.0で自前のdaydreamを動かしたところで表示がされなくなってしまうという現象に悩み始めて6時間ほど。
とてもシンプルな形のソースも拾ってきて実行したところ同様の結果になった。
ログを見てみると
10-15 23:06:04.876 1832-1832/? D/PhoneStatusBar: disable: < expand ICONS* alerts SYSTEM_INFO* back home recent clock search quick_settings >
10-15 23:06:05.000 1832-1832/? D/PhoneStatusBar: disable: < expand ICONS alerts SYSTEM_INFO back HOME* RECENT* clock SEARCH* quick_settings >
10-15 23:06:05.020 1832-1832/? D/PhoneStatusBar: disable: < expand ICONS alerts SYSTEM_INFO back home* RECENT clock SEARCH quick_settings >
10-15 23:06:05.022 1832-1832/? D/PhoneStatusBar: disable: < expand icons* alerts system_info* back home RECENT clock SEARCH quick_settings >
と言ったログが出る瞬間に消えていることから、PhoneStatusBarの挙動が変わったということなのだろうか?
そもそもPhoneStatusBarって?みたいな初心者なわけですが、AndroidではJBから大幅にWindowのレイヤー階層が変わったとかなんとか。Windowのレイヤーって話はちょこちょこ見ているものの正直直接どうのこうのできそうにないのでスルーしていた部分です。
似たような現象が発生したことがあるのはフルスクリーンにしたときに一定のタイミングで表示が消えてしまうという現象。
今まではロック画面が構築されたタイミングで落ちている感じだったので悩んでいた時もあったけど、まぁそういう仕様なのだとあきらめていました。
が、今回は何をどうやっても消えてしまうような感じになっています。
フルスクリーンのアプリではステータスバーの表示が絡んでいそうなので、もしかすると同じくPhoneStatusBarが関係している気もしないでもないわけで…
ドキュメントやSDKのソースを見ていてもこれと言ったヒントがまったく見えてこない。
さて…愚痴もこの辺でもう少し調べてみよう。
2015年10月16日金曜日
2015年10月15日木曜日
ようやくSDK23へ
今までどう足掻いてもダメだったSDK23でのコンパイル。
proguardを使わなければコンパイルは出来てはいたのですが、今まで使えなかったものを使わないというのはなんとも。
エラーメッセージを頼りにいろいろやっていたのですが結局どこかでつまずいてしまうという。
そして摩訶不思議なビルドを繰り返すとまた再度エラーになるとか、ファイル同期の罠にはまりつつ結局導き出した打開策は「SDK22で時期が来るまで待つ」という結論でしたが、マッシュルームが今朝NEXUS9に落ちてきて、手持ちのアプリの不具合もちょこちょこ見つかったので、ビルドを見直すかと…
proguard-rules.proのファイルの設定をいじって結局どこが原因か判断点かなかったのですが、結果を知った今だとなんとなくproguardのログを見ればわかったのかな?って思います。
私の場合は結局のところproguard-rules.proに
-keep class com.google.android.gms.** { *; }
-dontwarn com.google.android.gms.**
と追加してあげれば大丈夫だったという結論です。
そもそもgoogleさんのライブラリを使うためにいろいろと揺れている感じの設定事項のお話があるようですが、現状のSDK23ベースのproguardでは自前でルールを設定しなさい。という感じなのかな?
不要かもしれないけど追加したルールは
-keep class org.apache.http.** { *; }
-dontwarn org.apache.http.**
-keep class android.net.http.** { *; }
-dontwarn android.net.http.**
-keep class android.support.v7.** { *; }
-keep class android.support.v4.** { *; }
-keep class com.google.android.gms.** { *; }
-dontwarn com.google.android.gms.**
となっています。使ってないサポートライブラリもあったりしますが、経験上エラーで見たことのあるライブラリのapacheやnetも含めています。
とりあえず一つの問題が解決した(笑)
参考
http://stackoverflow.com/questions/31643339/errorexecution-failed-for-task-apppackagerelease-unable-to-compute-hash
answered Oct 8 at 17:26 のgoRGonさんに感謝!
proguardを使わなければコンパイルは出来てはいたのですが、今まで使えなかったものを使わないというのはなんとも。
エラーメッセージを頼りにいろいろやっていたのですが結局どこかでつまずいてしまうという。
そして摩訶不思議なビルドを繰り返すとまた再度エラーになるとか、ファイル同期の罠にはまりつつ結局導き出した打開策は「SDK22で時期が来るまで待つ」という結論でしたが、マッシュルームが今朝NEXUS9に落ちてきて、手持ちのアプリの不具合もちょこちょこ見つかったので、ビルドを見直すかと…
proguard-rules.proのファイルの設定をいじって結局どこが原因か判断点かなかったのですが、結果を知った今だとなんとなくproguardのログを見ればわかったのかな?って思います。
私の場合は結局のところproguard-rules.proに
-keep class com.google.android.gms.** { *; }
-dontwarn com.google.android.gms.**
と追加してあげれば大丈夫だったという結論です。
そもそもgoogleさんのライブラリを使うためにいろいろと揺れている感じの設定事項のお話があるようですが、現状のSDK23ベースのproguardでは自前でルールを設定しなさい。という感じなのかな?
不要かもしれないけど追加したルールは
-keep class org.apache.http.** { *; }
-dontwarn org.apache.http.**
-keep class android.net.http.** { *; }
-dontwarn android.net.http.**
-keep class android.support.v7.** { *; }
-keep class android.support.v4.** { *; }
-keep class com.google.android.gms.** { *; }
-dontwarn com.google.android.gms.**
となっています。使ってないサポートライブラリもあったりしますが、経験上エラーで見たことのあるライブラリのapacheやnetも含めています。
とりあえず一つの問題が解決した(笑)
参考
http://stackoverflow.com/questions/31643339/errorexecution-failed-for-task-apppackagerelease-unable-to-compute-hash
answered Oct 8 at 17:26 のgoRGonさんに感謝!
ラベル:
Android Studio,
SDK 23
スクリーンセイバーの挙動がおかしい
どうもスクリーンセイバーの挙動がおかしくなってしまった。
表示はされるが、15~30秒程度で画面が消失してしまう。
2つのパターン(handlerで動かしているものと、自前のスレッドで動かしているもの)で同様の現象が発生している。
原因がおそらく不完全な実装になっているということなのだろう。
対応策としてSDK22でコンパイルされているのでこれをSDK23に変更してコンパイルしてみること。
あとは…SDKのソースを追っかけるか、サンプルのソースを追っかける必要がある。
さて…これも早急に対応したい。
表示はされるが、15~30秒程度で画面が消失してしまう。
2つのパターン(handlerで動かしているものと、自前のスレッドで動かしているもの)で同様の現象が発生している。
原因がおそらく不完全な実装になっているということなのだろう。
対応策としてSDK22でコンパイルされているのでこれをSDK23に変更してコンパイルしてみること。
あとは…SDKのソースを追っかけるか、サンプルのソースを追っかける必要がある。
さて…これも早急に対応したい。
フルスクリーンのアプリの挙動がおかしい
ダメなシナリオ
1.アプリを起動してフルスクリーンに。
2.ナビゲーションバーを表示させBackさせる。
3.再度アプリを立ち上げると、フルスクリーンになるものの、ナビゲーションバーの表示部分が黒くなってしまう。
画面を回転させるか、キャッシュされているアプリを破棄し、再度アプリを起動させれば復帰する。
問題ないシナリオ
1.アプリを起動してフルスクリーンに。
2.ホームボタンでホーム画面に戻る。
3.再度アプリを起動するが、アクティビティーが破棄されていなかったため、復帰し無事フルスクリーンのままに。
さらに、ホームボタンではなくアプリ切り替えを行っても問題がなかったことを確認。
予想される問題点
おそらくナビゲーションバーのBackボタンを押したことによりActivityをアプリ側で破棄し、再度起動時に自力で再構築するときにフルスクリーンの対応が不完全ではないかと考えられる。
さて…すぐ対応できるかな…(=_=;
1.アプリを起動してフルスクリーンに。
2.ナビゲーションバーを表示させBackさせる。
3.再度アプリを立ち上げると、フルスクリーンになるものの、ナビゲーションバーの表示部分が黒くなってしまう。
画面を回転させるか、キャッシュされているアプリを破棄し、再度アプリを起動させれば復帰する。
問題ないシナリオ
1.アプリを起動してフルスクリーンに。
2.ホームボタンでホーム画面に戻る。
3.再度アプリを起動するが、アクティビティーが破棄されていなかったため、復帰し無事フルスクリーンのままに。
さらに、ホームボタンではなくアプリ切り替えを行っても問題がなかったことを確認。
予想される問題点
おそらくナビゲーションバーのBackボタンを押したことによりActivityをアプリ側で破棄し、再度起動時に自力で再構築するときにフルスクリーンの対応が不完全ではないかと考えられる。
さて…すぐ対応できるかな…(=_=;
2015年10月13日火曜日
2015年10月11日日曜日
2015年10月8日木曜日
TextView: テキストが自動的に折り返されないようにする。
TextViewで表示する幅が変わったときや内容が長くなった場合など自動的に折り返されてView自体の縦幅が長くなってしまう。
これを回避する方法は表示する内容を省略させることができます。
これを回避する方法は表示する内容を省略させることができます。
登録:
投稿 (Atom)