バージョンとか

手持ちの環境のバージョンのメモです。

SharedPreferences 非推奨のMODE_WORLD_READABLEで読み込めない

突然おかしな現象に陥りました。
別のアプリのSharedPreferencesの値が正しく参照されないという現象に。
これが起こったのが一通りコード修正が終わり、手持ちの端末にインストールしてたところNexus9(Android6.0.1)だけ設定をいくら変えても反映されない状態に。

さすがに非推奨となっている内容をそろそろ使用をやめようと思ってはいるので、良い機会なので書き換えようかなと。

改めて調べてみると代替えとなるContentProviderが予想以上にリソースを消費しそうなところと、アクセスを頻繁に行うのには向かなさそうというところが引っかかってしまいました。

非推奨とならない実装方法もあるのかもしれませんが、結局手軽に扱えそうなものが判らないのでとりあえず現状がっどうなっているのか調べることにしました。

まず値を設定している側のアプリは全く問題なく動いています。見かけ上もデバッグログもとくに変なエラーは吐いていません。
読み込む側のアプリも同様にエラーなども見当たりません。

ただ、結果として値を参照する側が明らかに読み込めていません。

コードにデバッグログを仕込んだところパッケージマネージャで値の入っているアプリを取得してgetSharedPreferencesでSharedPreferencesを取得するところは処理がちゃんと通っていることを確認しました。
さらにその先のgetIntなども行えています。が、エラーはありませんが、どうも値が読み込めていないようです。

アプリ自体に問題はなさそうなのでアンインストールとインストールを繰り返してみたところ、設定が目で不思議な現象に気づきました。
通常アンインストールを行うとSharedPreferencesの設定値は消えるはずなのですが、これがどうも消えていない様子。
と、するとあり得るのはAndroidの機能としてインストール時にクラウドから設定値が復元されているのではないかと感じました。

試しにAndroidの設定のバックアップと復元の「自動的に復元する」をオフにしてアンインストールとインストールを行ったところ値がデフォルトに戻ったのを確認。さらにこの状態で設定した状況が反映されていました。

再度「自動的に復元する」を有効にして同様の事を行ったところ、設定が反映されなくなって今いました。
この状態でアプリ情報からアプリのストレージに保存されているデータを消去して設定を行ったところ、これもまた正しく動作し始めました。

原因は自動復元によってSharedPreferencesファイルが復元されていることが原因でした。

gmsのプラグイン？

アプリで不可解なエラーが出始めて色々と確認しています。

リスナー系の実装方法

～Listenerというクラスの実装方法は色々あると思いますが、主に利用しているパターンは２つのパターンです。

①無名クラスで実装する方法
②メインとなるクラスにimplementsで実装してしまう方法
他にもちゃんと名前を付けたクラスを定義して実装する方法もありますが使ったことはありません。

実際のコード（例ではシークバーを扱っています）は次のようになります。
①の例
public class ～Activity extends Activity {
    :
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        :
        seekBar～.setOnSeekBarChangeListener(
            new SeekBar.OnSeekBarChangeListener() {
                public void onProgressChanged(SeekBar seekBar, int progress, boolean fromUser) {
                    //
                }
                public void onStartTrackingTouch(SeekBar seekBar) {
                    //
                }
                public void onStopTrackingTouch(SeekBar seekBar) {
                    //
                }
            }
        );
        :
    }
    :
}
②の例
public class ～Activity extends Activity
    implements SeekBar.OnSeekBarChangeListener {
    :
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        :
        seekBar～.setOnSeekBarChangeListener(this);
        :
    }
    :
    @Override
    public void onProgressChanged(SeekBar seekBar, int progress, boolean fromUser) {
        //
    }
    @Override
    public void onStartTrackingTouch(SeekBar seekBar) {
        //
    }
    @Override
    public void onStopTrackingTouch(SeekBar seekBar) {
        //
        switch (seekBar.getId()){
            case R.id.seekBar～:
                break;
        }
    }
    :
}

好みもありますが、個人的には①のほうがスッキリしていてコードも見やすいので好きなのですが、複数シークバーが有るときにはどうしても助長に見えます。また無名クラスとはいえ内部でクラスが生成されているのも気になります。（Javaが実際にどのように動作しているのかは理解していませんが）
②の場合は一つの時には何も考えなくてもよいのですが、複数ある場合は引数のseekBarを見てどのseekBarなのか判断する必要があります。コードには条件分岐が必要になるので複雑になってしまいます。ただしクラスの生成が発生していない分、余計な生成時間やメモリーがなさそうです。

まだどちらが良い悪いという結論が出せていません。

Android Sturio 2.0 Preview

確か先々週あたりから表示されるようになっていて、先週アップデートしました。
古いプロジェクトを開くとビルドはできるようですが、gradle関連のファイルやソース内のエラーや警告表示があってとりあえず気づいた点を書いておきたいと思います。

Android Studioでモジュール単位のビルドが不安定？

いままでコードを変更するときの影響があまり出ないようにするため、単一プロジェクト、単一モジュールで作成していました。一番の利点はビルドするときに目に見えない影響がほぼないことでしょう。欠点としてはライブラリのようなコードが散在してしまい、管理上はよくありません。
そのため、ほぼ同じコードが存在する複数のプロジェクトを単一プロジェクトでモジュール化してまとめています。

インポート文を自動で設定させる

こんな機能いらない。
ほんと要らない。

そもそもALT+ENTERで追加されるだけで十分じゃないか？

と思うわけですが。

こんな設定。

オフですオフ。

参考
Android Studio最速入門～効率的にコーディングするための使い方

コーディングは効率＝ケアレスミスをいかに減らすかです。

ちょｗ おまｗｗｗ

Android Studioに呪われ始めました…。

Android Studioのプロジェクト内モジュールのJavaソース

最近Androidよりも開発環境のAndroid Studioに問題が集中しています。

プロジェクト管理を簡単にしようと、とりあえず同様のソースを多重化させてアプリを作っていたのですが、そろそろ一本化させようかとあれやこれや奮闘し行き着いた先がモジュールという管理単位。

どうやってもモジュール分割ができない

Android Studio 1.5 Preview 2のアップデートを済ませ、一つのプロジェクトで複数のモジュールに分けてできれば一つのプロジェクトに複数のアプリをと頑張っています。
途中で色々なエラーに躓きながら、JDKも8をインストールしたり、そのためにリンクできないとか色々な状態に陥りましたが、なんとかapkファイルまでは作られるようにはなりました。

残念なことに並行してNDKの組み込みも行おうとしていて、うまくできないかと試したところやっぱりうまくいかない（笑）

あと一歩というところまでは来ている感じがするものの、うまくコンパイルが通る形にすると、肝心のオブジェクトファイルが無いという…。
com.android.model.libraryの指定しているライブラリ側のbuild.gradle内にandroid.productFlavors {を記述すると途端にライブラリ側のモジュールがどこかに消え去ってしまっているようです。
まぁ無茶なんだなとあきらめるというのがいまのところいいんじゃないかという結論。

 Information:Gradle tasks [clean, :library:generateAllDebugSources, :library:generateAllDebugAndroidTestSources, :library:compileAllDebugSources, :library:compileAllDebugAndroidTestSources, :app:generateDebugSources, :app:generateDebugAndroidTestSources, :app:compileDebugSources, :app:compileDebugAndroidTestSources, :samplelib:generateDebugSources, :samplelib:generateDebugAndroidTestSources, :samplelib:compileDebugSources, :samplelib:compileDebugAndroidTestSources]
:app:clean
:library:clean
:samplelib:clean
:library:preBuild UP-TO-DATE
:library:preAllDebugBuild UP-TO-DATE
:library:checkAllDebugManifest
:library:prepareAllDebugDependencies
:library:compileAllDebugAidl
:library:compileAllDebugRenderscript
:library:generateAllDebugBuildConfig
:library:generateAllDebugAssets UP-TO-DATE
:library:mergeAllDebugAssets
:library:generateAllDebugResValues UP-TO-DATE
:library:generateAllDebugResources
:library:packageAllDebugResources
:library:processAllDebugManifest
:library:processAllDebugResources
:library:generateAllDebugSources
:library:preAllDebugAndroidTestBuild UP-TO-DATE
:library:prepareAllDebugAndroidTestDependencies
:library:compileAllDebugAndroidTestAidl
:library:compileLint
:library:copyAllDebugLint UP-TO-DATE
:library:mergeAllDebugProguardFiles UP-TO-DATE
:library:processAllDebugJavaRes UP-TO-DATE
:library:compileAllDebugJavaWithJavac
:library:packageAllDebugJar
:library:packageAllDebugJniLibs UP-TO-DATE
:library:packageAllDebugLocalJar UP-TO-DATE
:library:packageAllDebugRenderscript UP-TO-DATE
:library:bundleAllDebug
:library:copyArm64-v8aDebugAllRaincharSharedLibraryGdbServer
:library:createArm64-v8aDebugAllRaincharSharedLibraryGdbsetup
:library:compileArm64-v8aDebugAllRaincharSharedLibraryRaincharMainC
:library:linkArm64-v8aDebugAllRaincharSharedLibrary
:library:stripSymbolsArm64-v8aDebugAllRaincharSharedLibrary
:library:arm64-v8aDebugAllRaincharSharedLibrary
:library:copyArmeabi-v7aDebugAllRaincharSharedLibraryGdbServer
:library:createArmeabi-v7aDebugAllRaincharSharedLibraryGdbsetup
:library:compileArmeabi-v7aDebugAllRaincharSharedLibraryRaincharMainC
:library:linkArmeabi-v7aDebugAllRaincharSharedLibrary
:library:stripSymbolsArmeabi-v7aDebugAllRaincharSharedLibrary
:library:armeabi-v7aDebugAllRaincharSharedLibrary
:library:copyArmeabiDebugAllRaincharSharedLibraryGdbServer
:library:createArmeabiDebugAllRaincharSharedLibraryGdbsetup
:library:compileArmeabiDebugAllRaincharSharedLibraryRaincharMainC
:library:linkArmeabiDebugAllRaincharSharedLibrary
:library:stripSymbolsArmeabiDebugAllRaincharSharedLibrary
:library:armeabiDebugAllRaincharSharedLibrary
:library:copyMips64DebugAllRaincharSharedLibraryGdbServer
:library:createMips64DebugAllRaincharSharedLibraryGdbsetup
:library:compileMips64DebugAllRaincharSharedLibraryRaincharMainC
:library:linkMips64DebugAllRaincharSharedLibrary
:library:stripSymbolsMips64DebugAllRaincharSharedLibrary
:library:mips64DebugAllRaincharSharedLibrary
:library:copyMipsDebugAllRaincharSharedLibraryGdbServer
:library:createMipsDebugAllRaincharSharedLibraryGdbsetup
:library:compileMipsDebugAllRaincharSharedLibraryRaincharMainC
:library:linkMipsDebugAllRaincharSharedLibrary
:library:stripSymbolsMipsDebugAllRaincharSharedLibrary
:library:mipsDebugAllRaincharSharedLibrary
:library:copyX86DebugAllRaincharSharedLibraryGdbServer
:library:createX86DebugAllRaincharSharedLibraryGdbsetup
:library:compileX86DebugAllRaincharSharedLibraryRaincharMainC
:library:linkX86DebugAllRaincharSharedLibrary
:library:stripSymbolsX86DebugAllRaincharSharedLibrary
:library:x86DebugAllRaincharSharedLibrary
:library:copyX86_64DebugAllRaincharSharedLibraryGdbServer
:library:createX86_64DebugAllRaincharSharedLibraryGdbsetup
:library:compileX86_64DebugAllRaincharSharedLibraryRaincharMainC
:library:linkX86_64DebugAllRaincharSharedLibrary
:library:stripSymbolsX86_64DebugAllRaincharSharedLibrary
:library:x86_64DebugAllRaincharSharedLibrary
:library:compileAllDebugSources
:library:assembleAllDebug
:library:processAllDebugAndroidTestManifest
:library:compileAllDebugAndroidTestRenderscript
:library:generateAllDebugAndroidTestBuildConfig
:library:generateAllDebugAndroidTestAssets UP-TO-DATE
:library:mergeAllDebugAndroidTestAssets
:library:generateAllDebugAndroidTestResValues UP-TO-DATE
:library:generateAllDebugAndroidTestResources
:library:mergeAllDebugAndroidTestResources
:library:processAllDebugAndroidTestResources
:library:generateAllDebugAndroidTestSources
:library:processAllDebugAndroidTestJavaRes UP-TO-DATE
:library:compileAllDebugAndroidTestJavaWithJavac
:library:compileAllDebugAndroidTestSources
:app:preBuild UP-TO-DATE
:app:preDebugBuild UP-TO-DATE
:app:checkDebugManifest
:app:preReleaseBuild UP-TO-DATE
:app:prepareComAndroidSupportSupportV42220Library
:app:prepareComGoogleAndroidGmsPlayServicesAds810Library
:app:prepareComGoogleAndroidGmsPlayServicesAnalytics810Library
:app:prepareComGoogleAndroidGmsPlayServicesAppindexing810Library
:app:prepareComGoogleAndroidGmsPlayServicesBasement810Library
:app:prepareDebugDependencies
:app:compileDebugAidl
:app:compileDebugRenderscript
:app:generateDebugBuildConfig
:app:generateDebugAssets UP-TO-DATE
:app:mergeDebugAssets
:app:generateDebugResValues UP-TO-DATE
:app:generateDebugResources
:app:mergeDebugResources
:app:processDebugManifest
:app:processDebugResources
:app:generateDebugSources
:app:preDebugAndroidTestBuild UP-TO-DATE
:app:prepareDebugAndroidTestDependencies
:app:compileDebugAndroidTestAidl
:app:processDebugAndroidTestManifest
:app:compileDebugAndroidTestRenderscript
:app:generateDebugAndroidTestBuildConfig
:app:generateDebugAndroidTestAssets UP-TO-DATE
:app:mergeDebugAndroidTestAssets
:app:generateDebugAndroidTestResValues UP-TO-DATE
:app:generateDebugAndroidTestResources
:app:mergeDebugAndroidTestResources
:app:processDebugAndroidTestResources
:app:generateDebugAndroidTestSources
:app:processDebugJavaRes UP-TO-DATE
:app:compileDebugJavaWithJavac
C:\AndroidStudioProjects\RainOfCharacter\app\src\main\java\jp\rallwell\siriuth\rainchardream\SirDreamService2.java
Error:(17, 39) エラー: パッケージjp.rallwell.siriuth.raincharlibは存在しません
Error:(33, 24) エラー: シンボルを見つけられません
シンボル:   クラス DreamEffect
場所: クラス SirDreamService2
Error:(38, 22) エラー: シンボルを見つけられません
シンボル:   クラス DreamEffect
場所: クラス SirDreamService2
Error:(174, 26) エラー: シンボルを見つけられません
シンボル:   クラス DreamEffect
場所: クラス RenderingThread
Error:(177, 53) エラー: シンボルを見つけられません
シンボル:   クラス DreamEffect
場所: クラス RenderingThread
C:\AndroidStudioProjects\RainOfCharacter\app\src\main\java\jp\rallwell\siriuth\rainchardream\SirDreamService.java
Error:(24, 39) エラー: パッケージjp.rallwell.siriuth.raincharlibは存在しません
Error:(55, 24) エラー: シンボルを見つけられません
シンボル:   クラス DreamEffect
場所: クラス SirDreamService
Error:(62, 22) エラー: シンボルを見つけられません
シンボル:   クラス DreamEffect
場所: クラス SirDreamService
C:\AndroidStudioProjects\RainOfCharacter\app\src\main\java\jp\rallwell\siriuth\rainchardream\RainCharDreamService.java
Error:(3, 39) エラー: パッケージjp.rallwell.siriuth.raincharlibは存在しません
Error:(4, 39) エラー: パッケージjp.rallwell.siriuth.raincharlibは存在しません
Error:(10, 15) エラー: シンボルを見つけられません
シンボル:   クラス DreamEffect
場所: クラス RainCharDreamService
Error:(11, 21) エラー: シンボルを見つけられません
シンボル:   クラス RainCharBitmapEffect
場所: クラス RainCharDreamService
C:\AndroidStudioProjects\RainOfCharacter\app\src\main\java\jp\rallwell\siriuth\rainchardream\RainCharMDreamService.java
Error:(3, 39) エラー: パッケージjp.rallwell.siriuth.raincharlibは存在しません
Error:(4, 39) エラー: パッケージjp.rallwell.siriuth.raincharlibは存在しません
Error:(11, 12) エラー: シンボルを見つけられません
シンボル:   クラス DreamEffect
場所: クラス RainCharMDreamService
Error:(12, 21) エラー: シンボルを見つけられません
シンボル:   クラス RainCharMEffect
場所: クラス RainCharMDreamService
エラー16個
Error:Execution failed for task ':app:compileDebugJavaWithJavac'.
> Compilation failed; see the compiler error output for details.
Information:BUILD FAILED
Information:Total time: 44.405 secs
Information:17 errors
Information:0 warnings
Information:See complete output in console

gradleのバージョンやらプラグインなどのしがらみも結構きつく、バージョンを上げようとするとプラグイン側で2.5以外は対応していないとか出てきました。無効化できそうですけど限界です（笑）

そもそも別建ててNDKのオブジェクトを作成すればおそらくそれでいいような気がするし。
まだまだうまく行かない（笑）

Error:Unable to load class 'org.gradle.nativeplatform.internal.DefaultBuildType_Decorated'.

よくわからない状態になったらこんなエラーメッセージが表示されるようになってビルドも何も通らなくなってしまった。

Error:Unable to load class 'org.gradle.nativeplatform.internal.DefaultBuildType_Decorated'. Possible causes for this unexpected error include:

• You are using JDK version 'java version "1.7.0_79"'. Some versions of JDK 1.7 (e.g. 1.7.0_10) may cause class loading errors in Gradle. Please update to a newer version (e.g. 1.7.0_67). Open JDK Settings
• Gradle's dependency cache may be corrupt (this sometimes occurs after a network connection timeout.) Re-download dependencies and sync project (requires network)
• The state of a Gradle build process (daemon) may be corrupt. Stopping all Gradle daemons may solve this problem. Stop Gradle build processes (requires restart)
• Your project may be using a third-party plugin which is not compatible with the other plugins in the project or the version of Gradle requested by the project.

In the case of corrupt Gradle processes, you can also try closing the IDE and then killing all Java processes.

挙句の果てにJDK 8u60もインストールして 1.8にバージョンアップさせたりしてもやはりだめ（笑）

結局検索してみると、いつものスタックオーバーフローが引っかかり
Android Studio: Gradle Build fails with error: Unable to load class 'com.android.build.gradle.ndk.NdkPlugin' にて

Vinod Khosla「Try cleaning your project and re-build.」

とのこと。プロジェクトのクリーンとリビルドを試しなさい。ってことでエラーがまともに出るようになりました。
以前おかしな挙動が収まらなかったときは、プロジェクト内の自動生成物をほとんど削除すればまともになったのですが、正当法はこちらなんでしょうね。

五里霧中な開発環境

いったい何が問題なのかと言えばGoogle playのライセンスチェックがorg.apache.httpに依存している状態なのにもかかわらず、SDK 23からorg.apache.httpがライブラリから外されるという状態になりました。

ネイティブ クラッシュ（/system/lib64/libskia.so）

一通りダウンロード数の多いアプリの変更が済み一夜明けてみると、DeveloperConsoleにバグレポートのカウントが上がってました。

TextureViewしかないのかな？

問題が発覚してからほぼ丸一日SampleのソースコードとSDKのソースコードをにらめっこしていた。
色々と確定した要素が一晩経ってから判明したことは、どうも描画が行われなくなるタイミングががロック画面が生成されたタイミングで表示されなくなるということが確定要素として分かった。

Android 5.xまではロック画面の生成タイミングが若干不安定だったのか、Daydreamの時にだけすこし挙動が異なっていたのかはわからないが、Android 6.0 からはロックまでのタイミングと、スリープまでのタイミングの扱いが今までと変わっているということのようだ。（まだ混乱してる感じが強く日本語になってない（笑））

ちょっと言い方を変えると、Daydreamの表示されている意味合いが変わったのかともとれる。5.xまではDaydreamの表示が行われ、スリープのタイミングまでなにも行動は起こされなかったか、またはロック画面の生成が不安定だったのかもしれない。

Daydreamを動作直後に話を限定するともう少し具体的になる。

6.0ではDaydreamの表示が行われたタイミングでロック画面とスリープ画面のカウントダウンが始まり、ロック画面までの時間が来た時点でロック画面が生成され、表示上のWindowレイヤーが変更されている。
ただし、この状態で画面スリープまでの時間が経過していなければまだ表示は行われている。
逆に先に画面スリープの時間がロック時間よりも短くても画面は表示されたままとなる。

その後、画面スリープまでの時間が経過してもDaydreamの表示は行われたままとなる。
インタラクティブモードではないDaydreamの場合は、この状態で画面タッチなどを行いDaydreamが終了するとロック画面の時間が経過していなくてもスリープまでの時間が経過していればロック画面が表示される。

おそらく仕様としてその辺が整理されたのかもしれない。
挙動も納得の行く動作結果になっていると感じます。

さて、ここまで行くまでにソースを色々と確認していました。

標準のDaydreamとして時計がありますが、時計の実装方法はとてもシンプルに行われていて、Daydream独自のコードはほとんどありません。
実際の処理の中身はカスタムビューとして定義されています。とくにSurfaceViewが使われているわけでもなく、一般的なView要素として表示が行われているため、Android的にはものすごくスマートな実装方法になっています。

またもう一つのColorsは、SurfaceViewに近いおそらくGLSurfaceViewで実装され、描画もほとんどView側で処理され最終的にはOpenGLに表示は委ねられている形になっています。

どちらも個人的に一般的だと思っていたSurfaceViewでの実装ではなく、なんというかマニアックな実装方法だと感じています。

ここでソースコードを忘れて結果だけとらえれば「SurfaceViewがダメなんじゃね？」的な発想になりますが、この時点ではまだSurfaceViewを悪く考えることができませんでした（笑）
結果、シンプルなDaydreamのソースを作り、そのあとlayoutファイルでTextViewとSurfaceViewの要素のものを画面に表示させていろいろと試したところ、TextViewの内容はいつでもどのタイミングでもしっかりと表示され、同時に表示されているSurfaceViewはロック画面が生成されていると思われるタイミングで描画しなくなっているという結果が確定しました。

ではSurfaceViewがダメならいったいどうすれば良いのだろうと言う事に本題が（ようやく）移行します。もうこの時点でほぼ丸一日、どんだけどんくさいんだよ…。

さて、選択肢は色々ありますね？ あるのかな？
アプリをできるだけ手軽に修正したいというのが前提になります。
OpenGL化するには色々と面倒なことになりそうです。
ほかは？？
と、いろいろ見ていましたが前から気になっていたSurfaceViewの下のTextureViewというものが使えるのかな？という期待で検索してみました。

Android 勉強会 #2 TextureViewのご紹介

結果としてはほぼ代用できそうです。

そのままの状態でCanvasが扱えるのが一番の利点でしょうか。
実際にSurfaceViewのものを強引にTextureViewに置き換えて実行してみます。

ちゃんとまともに動作するのがようやく確認できました。

例外処理の発生タイミングがわからないのと、API14以降というハードルが残っていますが、API14以降というのはそもそもDaydreamがAndroid 4.2(Jelly Bean MR1)の17なので問題はありません。古いバージョンに対応しているのはちょっと対応に悩みそうです。

daydreamで表示されなくなるという現象

Android 6.0で自前のdaydreamを動かしたところで表示がされなくなってしまうという現象に悩み始めて６時間ほど。

とてもシンプルな形のソースも拾ってきて実行したところ同様の結果になった。

ログを見てみると

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のソースを見ていてもこれと言ったヒントがまったく見えてこない。

さて…愚痴もこの辺でもう少し調べてみよう。

ようやく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さんに感謝！

スクリーンセイバーの挙動がおかしい

どうもスクリーンセイバーの挙動がおかしくなってしまった。

表示はされるが、１５～３０秒程度で画面が消失してしまう。

２つのパターン（handlerで動かしているものと、自前のスレッドで動かしているもの）で同様の現象が発生している。

原因がおそらく不完全な実装になっているということなのだろう。

対応策としてSDK22でコンパイルされているのでこれをSDK23に変更してコンパイルしてみること。
あとは…SDKのソースを追っかけるか、サンプルのソースを追っかける必要がある。

さて…これも早急に対応したい。

フルスクリーンのアプリの挙動がおかしい

ダメなシナリオ

1.アプリを起動してフルスクリーンに。
2.ナビゲーションバーを表示させBackさせる。
3.再度アプリを立ち上げると、フルスクリーンになるものの、ナビゲーションバーの表示部分が黒くなってしまう。

画面を回転させるか、キャッシュされているアプリを破棄し、再度アプリを起動させれば復帰する。

 問題ないシナリオ
1.アプリを起動してフルスクリーンに。
2.ホームボタンでホーム画面に戻る。
3.再度アプリを起動するが、アクティビティーが破棄されていなかったため、復帰し無事フルスクリーンのままに。

さらに、ホームボタンではなくアプリ切り替えを行っても問題がなかったことを確認。

予想される問題点

おそらくナビゲーションバーのBackボタンを押したことによりActivityをアプリ側で破棄し、再度起動時に自力で再構築するときにフルスクリーンの対応が不完全ではないかと考えられる。



さて…すぐ対応できるかな…(=_=;

Android Studio 1.5 Preview へのアップデートにて

早速アップデートしましょうかね。

sleep(0)

特定の処理で明らかにsleep(0)を実行するのは解っていたのですが、特に害はないと思ってそのままにしていました。

TextView: テキストが自動的に折り返されないようにする。

TextViewで表示する幅が変わったときや内容が長くなった場合など自動的に折り返されてView自体の縦幅が長くなってしまう。

これを回避する方法は表示する内容を省略させることができます。

お知らせが来てました

2015/09/23 古いC2DMが廃止された模様。

今度は…

ビルドが通らなくなり今度は
Error:Execution failed for task ':app:dexRelease'.
> com.android.ide.common.process.ProcessException: No files to pass to dex.
といったメッセージが表示されるパターンに陥りました。

またしてもproguardでエラーが止まらない

NDKで遊んでいたプログラムをリリースを行おうとしていたところ、なかなかproguardが言うことを聞いてくれなく、仕方がないのでNDK部分を外してビルドを行っていたところ、ドハマりしました。

NDKで必要な変更を行った部分を元に戻してあげれば戻るはずなのだが、これが本当によくわからない状況に陥ってしまいました。

SSIDのスペイン語表記

Google Playで公開している小物無料アプリのSSIDを表示するだけのただそれだけのアプリ。

評価は特に気にするでもなく、当初から自分用に欲しかったアプリで無駄な通信を行わないコンパクトなものということで単機能に特化しています。

色を変えたいという要望とともに、色を変えられるように別の設定だけのアプリに分割していたりします（そちらは広告をつけたので設定画面を開くと無駄な通信が発生します）。
実装は単純なのですが、ウィジェットを作ってみるときになるのが、起動直後に表示がされないタイミングが発生していたり、その時間をできるだけ短くするために実装方法を変えてみたり地味ながら結構苦労はしています。

ネイティブコード

Windows 64bit版のAndroid Studio 1.3.1環境でようやくコンパイル～実行までたどり着けました。
Android Studioのバージョンが上がるたびにまだ実装完了しているという状態ではないのでどうしても設定にいろいろと調整が必要で、具体的にどこの情報が正しいのか判断するのが一番むつかしいです。

ビルド時に表示されるエラーメッセージも現状では参考にならない情報が吐き出されていたりするので、本当に情報に翻弄されてしまいます。

どうしたものか…プロジェクトとモジュールとフレーバー

ただの愚痴になってしまいました。

ads:adSize="SMART_BANNER"で画面を横にすると表示されなくなる

バナー表示広告で今までads:adSize="BANNER"を使ってきましたがスクリーンサイズによって左右に余白が出来てしまいちょっと残念だったので最近はads:adSize="SMART_BANNER"を使っていました。
昨日play-serviceのバージョンを変えたついでにSMART_BANNERにしたところなぜか広告が表示されなくなり、何かやらかしたと思い、何が悪いのか悩んだまま気がついたら寝落ちしていました(笑)

統合されたものはちゃんと分割されていた

昨日統合されすぎて巨大になっていたcom.google.android.gms:play-services:7.5.0ですが、ちゃんと分割されているようです。

Setting Up Google Play Services

ちゃんとドキュメントは見ないとダメということで(笑)

ちょっ とこれは…

SDKの更新を行った後に、何も考えずに更新されているライブラリのバージョンを上げてみたところAPKのアップデートでえらい違いがあったのでリリース前に元に戻して再構築。

そういえばAPKのサイズが今まで1M程度だったのが2M超えててまさかと思いました。

SurfaceのCanvasはダブルバッファなのかトリプルバッファなのか？

一時期Chromeでダブルバッファリング絡みのバグがあって非常に残念な時期があったが、どうも手元のA1000-Fはトリプルバッファなんじゃないかという感じがしています。

いろいろな所に書かれている話としては「SurfaceViewはダブルバッファリングなので～」という感じに書かれていますが、Android4.1の（現時点で古い感じの）端末でトリプルバッファということは、グラフィックスチップに依存する部分なのでしょうね。

Bitmap setWidth setHeight setConfig reconfigの罠

ビットマップの再割り当てを減らすために再生成せずに作り変えることが出来そうなメソッドがあったので早速使ってみました。

APILEVEL 19(KitKat)以降で利用できるようなのでそれも加味して実際に動かしてみると

java.lang.IllegalArgumentException: Bitmap not large enough to support new configuration
at android.graphics.Bitmap.nativeReconfigure(Native Method)

早速例外が。

最初はスレッドが干渉して例外になってしまうのかと考えsynchronizedで包んでやりました。
同期させてしまうのならついでにCanvasも一緒に生成させるようにしてあげて再実行。

最初は上手く行ったと思ったら結局同じ例外が出てしまい、ちょっとありがちな制約が気になってドキュメントを見てみると…

This method can be used to avoid allocating a new bitmap, instead reusing an existing bitmap's allocation for a new configuration of equal or lesser size. If the Bitmap's allocation isn't large enough to support the new configuration, an IllegalArgumentException will be thrown and the bitmap will not be modified.

ありましたね…「a new configuration of equal or lesser size」 限定という罠です。
再割り当てするには割り当てられるメモリのサイズが同じか小さい場合ということで、大きくなった場合は、IllegalArgumentExceptionが発生して変更されないという話です。

経験上この辺の話は良くあることなので当たり前ですけど、やっぱりなんともということでした。
メモリの再割り当てを考えればへたに食いつぶすよりは素直に新たに割り当てたほうがメモリ効率は良くなるんじゃないかなぁって思うので結局毎回createすることにしました。
ただ、Canvasは毎回生成するよりは使いまわしてしまったほうが良さそうなので同期はそのままにしておきましょうかね。

Nexus 9 Android 5.1.1

ふときづくと通知が来ていました。 5.0の動作環境がなくなるのは残念な気持ちもありますが、悩みながらもアップデートしてしまいました。

AndroidManifest.xmlの変更後のアップデートインストール

AndroidManifest.xmlの変更を行ってapkをGoogleDriveなどから更新する場合どうも値が上手く反映されていない場合がある。

例えば<activity>タグ内に android:excludeFromRecents="true" を追加した時のことだが、更新後にアプリの履歴から変更したアクティビティーを消した後に、ランチャーから起動しても履歴に表示されてしまった。

ファイルをオープンする時にダイアログが開いてくれない

Android Studio 1.2 Beta の使い勝手が地味に悪くなっている。
プロジェクトファイルをオープンする時に今までは「新たにウィンドウを開くか、それともこのウィンドウに開くか？」と尋ねられたのにそれがなくなっている。

バグなのか仕様なのかわからないが、ちょっと使い勝手が悪くなっている。

リオープンの時の設定は生きているようなので、そちらを使えということなのだろうか？

Android Studio 1.2 Beta

一昨日の寝る前にアップデート通知が来たのでアップデートをかけてみました。

PocketWifiの切り替えタイミングが知りたい。

Pocket WIFIのON OFFだけでは

WIFI_STATE_CHANGED_ACTION
NETWORK_STATE_CHANGED_ACTION

だけでは何も送られてこない。WIFIをONの状態からPocketWifiをONにした場合は、WIFIも同時にON/OFFされるので上記２つのタイミングだけで十分なように思えたが、他の何が必要なのか？

Android 5.0.1 でDaydreamが動かない

早速入れておこうと思うスクリーンセイバーですが、なぜか動作せず。
現象としてはスクリーンセイバーを選択して「今すぐ表示」 を選んでもなぜか時計が表示されるという不可解な現象。
最初はAndroidのバグか！と思いながらも他のものを選択すると正しく動作するので、時間ができたときに対応しようと悔しい思いをしながら寝た訳ですが、早速デバッグしてみます。

初心者がハマったインテントフィルター

夜な夜なアプリを書き換えててハマりました。

apkのパッケージIDとjavaのパッケージ名

普通一般的にapkのパッケージIDとjavaのパッケージ名をわざと変える必要なんて無いと思います。

しかし、私は間違ったパッケージ名をつけてしまいました。この状況をなんとかしたい。という一念の元、名称の変更を行ってみました。

うまくゆかないちょっと気になることをメモ書き

アプリを作って使っていて気になって原因はわからないものの解消できたものと、原因が不明なものとが２つあるのでメモ書き。

Singletonパターン

実際に書籍などでデザインパターンに関するものを読んだことは無いのですが、javaを触っていく以上少なからず目を通しておいたほうが良いかもなと感じてはいます。

手持ちのアプリで動作が少々怪しい部分があるのでどうすればその部分を排除できるかという観点に基づいて考えた結果、まずはここからかな？というところでインスタンスが万が一複数できてしまっていたらよくは無いと考え、検索してみてみました。

Android studioのタイトル表示

結構不思議に思っていた矛盾。

結構前に名前を変えました。もちろんパッケージ名も変えてマニフェストも変えたりして最終的にPlayStoreのアプリの情報も新たに作り直して。（それでも途中のパッケージ名のスペルミスが発覚しているものの、結局現状そのままです(笑)）

ExampleAppWidgetProvider.javaのコードバグ

多分すごくどうでもいいことですが気づいたので書いておきます(笑)

後で書くかもしれませんけど、元々はWidgetの挙動がどうしても気に入らないので動作をちょっと細かく見ていたところで気がつきました。

見ることのできるWidgetのコードをコンパイルして動かしたりしていて、やっぱりSDKのコードも見て見ないとダメかなとおもってみたところちょっとした違和感のあるコードが。

スクリーンセイバー（Daydream）のメモめも

どうも上手く行かない。
処理自体は流れるものの、スクリーンセイバーが表示される時に画面が一度ちらついてしまう。

スクリーンセイバー(Daydream)は開始する時に表示されている画面からフェード効果で切り替わっているのだが、いきなり描画しているものがブレンドされずにそのまま表示されてしまう。結果としてちらつきが発生している。

新規プロジェクトのgradleのエラー

SDK 22をインストールして実際に新規のアクティビティをもったプロジェクトを作成すると雛形が作成されてレイアウトの表示でレンダラのエラーが発生し、さらに下記のエラーが表示されました。


Error:(23, 13) Failed to resolve: com.android.support:appcompat-v7:22.+ Install Repository and sync project
Show in File
Show in Project Structure dialog

SDK 21 から 22 への変更時の覚書

SDK Lvel 22が公開されているのでファイルを開けたついでにリビルドをしています。

SDK Level 22で新規に作成してみるとちょっとまだ上手くコンパイルができない感じがするので少し怖いのです。

LiveWallpaper

描画テストを兼ねてLiveWallpaperを作ってみました。
元になりそうなソースはいろいろと転がっているのですが、実際にコンパイルして実行させるまでにまずいろいろと躓くこと躓くこと。

SDKサンプルを見ればいいのは解っているものの、どうもSDKのソースは余計なものが多すぎて目的の部分を知るまでにさらに他のことも知らないと解らないソースとなっているるのでほとんど目を通していません。（ダメデスね）

エミュレータのAndroid1.5でウィジェット一覧のアイコンが表示されない

原因は不明ですが、なぜかウィジェット一覧のアイコンが抜けている状態に。

AppWidgetProviderのonDeletedのバグ

AppWidgetProviderクラスのonDeletedには概知のバグがありonDeletedが呼ばれるタイミングで呼び出されないというバグがあるそうです。
この現象はonReceiveメソッドをオーバーライドすることで回避可能なのでドキュメントにもその実装のコードが記されています。
しかしながら、本格的に対応を行うとどうしても実行時のAPI実装Levelを元にして処理を分岐させる必要があり、そのためにバージョンチェックを行おうとして前回の記事に至りました。

Androidのバージョン取得

私は最近になってAndroidに触り始めたので過去の資産などほとんど無いのですがやはりどうせなら古い旧式のバージョンでも動いたほうがいいと欲を出したところ意外な落とし穴がありました。

intentの追加パラメータ

ActivityやServiceにパラメータを渡したい時など

// Serviceの起動側
Intent intent = new Intent(this, MyService.class);
intent.putExtra("Param", "text");
this.startService(intent);

// Service側
@Override
protected void onHandleIntent(Intent intent) {
    Log.d("MyService", "Param:" + intent.getStringExtra("Param"));
}

onStartCommand で受け取れるような気がする？

動的な配列

ArrayList

ArrayList arrayList = new ArrayList();
arrayList.add("text");

arrayList.add(new Byte(1));

Open GL のエラー

とりあえずどこを見ればいいのか全くわからないが、初期化処理でエラーが出てしまいどこがだめなのかすら見当がつかなかった。

 glError 1280

出てきたコードはこのエラー番号。
内容は「GL_INVALID_ENUM 無効な列挙　GLenum型の引数が範囲を超えている」らしいです。

Touch Screen Testを作った理由

なんでもいいからアプリを作りたい！というようなレベルではなく、購入したタブレットのタッチパネルがおかしくなったのでそれの様子を見るために作ったのが最初です。

筆圧の対応

Tegra NOTE7のタッチパネルは筆圧に対応しているというのも売りの一つでした。
対応アプリがあればそれなりに描けるものの結構癖があります。実際にどんな感じなのか試そう試そうとは思っていました。
ついでなのでタッチパネルテストアプリで遊んでみました。

ActionBarActivityからActivityへ

互換性の問題からActivityではなくサポートライブラリに含まれるActionBarActivityを使ったほうがいいのかもしれないと使ってみましたが、あまり関係はなさそう。
旧バージョンでもv21以上のマテリアルデザインっぽい部分が再現される部分もありますが、正直微妙。
いろいろなところでも書かれているので自分メモです(笑)

OpenGLでちょっと遊んでみた

サンプルを元に少し遊んでみました。

OpenGL

なんとなくプログラムにかかわるどうでもいいようなネタを書きなぐるようなブログになりつつありますが、今回は懲りずにOpenGLの話です。
OpenGLも触り始めたのは随分昔のことですが実際にあれこれ使ったことはありませんでした。
本格的にやろうにも実用的に重かったというのが正直なところでした。
ハードウェアもナシにテクスチャもないポリゴンを描画するだけでもリアルタイムで使うには程遠い感じだったのですが、それでもいろいろと遊んでは居ました。