「縁側」-みんなが作る掲示板-からのお知らせ
縁側からのお知らせ

縁側をご利用いただく際のルール&マナー集を用意いたしました
ユーザーの皆様に楽しくご参加いただけるよう、主に投稿時の注意点などをまとめています。
ご投稿の前には必ずご一読をお願いいたします。詳しくはこちら⇒「縁側 ルール&マナー

紹介文

残念ながらg07は不具合が多いと言われています。
私の利用環境では大きな問題は感じていませんが、時々理解出来ない事(表示など)はあります。

g07のハードスペックはCPU等は若干非力ですが、全体で見れば高コスパです。
ただ、ソフト面は殆ど素のAndroidみたいで、OSが持っているバグもそのまま出てきてしまった面もある気がしてます。
きっと、ソフト面への投資を抑える事で、高コスパを実現したのだと思います。

個人持ちの初Androidスマホがg07だったのが良かったのか悪かったのか分かりませんが、お陰様でいろいろな事を勉強する事が出来ました。

今後どうなるかは分かりませんが、もし何か不思議な事があっても原因が絞り込めれば回避策も見つかるかも知れないので、今まで調べた事なども残しておきます。

他機種でも共通な部分もあると思いますが、確認していないので分かりません。

試行なので予告なく削除するかも知れません。

  • がんばれg07の掲示板
  • がんばれg07の伝言板
  • がんばれg07の投稿画像
この掲示板は閲覧専用です(運営者のみが投稿できます)。

このページのスレッド一覧

前のページへ次のページへ


がんばれg07

タグ:

その1:adbの接続や起動等について

・接続端末の確認
 adb devices

 ※実行結果(出力形式)は接続方法によって異なる。
  USB接続の場合
   List of devices attached
   製造番号(メーカによって異なるかも) device

  Wi-Fi接続の場合
   List of devices attached
   IPアドレス:ポート番号 device
   
 ※adbが起動していない場合は下記メッセージが出て自動起動する。
  これは他のadbコマンドでも同様で明示的にadbを起動した時と同じメッセージ
 * daemon not running. starting it now on
port 5037 *
 * daemon started successfully *
 
 ※端末が未接続の場合でもエラー表示等は無く、メッセージ2行目が無いだけ。

・adbの起動と停止
 起動
  adb start-server

  ※adbが起動していない場合のみ、前述のメッセージが出力される。
 
 停止
  adb kill-server
  
  ※adbが起動していない場合のみ下記メッセージを出力する。
   * server not running *
   
 ※接続形式を変更した場合やadbの動作がおかしい時にkill→startでadbが再起動させる。
 ※Wi-Fi接続が確立している状態でUSB接続すると別の端末が接続されたと認識される。
  この場合はadbコマンドの送信先を明示する必要があるので、面倒でも再起動したほうが良い。
 
・Wi-Fi接続する時のポート番号の指定
 adb tcpip ポート番号
 
 ※adbが起動し端末が接続された状態の場合は下記メッセージを出力する。
  restarting in TCP mode port: ポート番号
  
 ※指定可能なポート番号は5555〜5585の奇数番号
 ※複数のデバイスを同時接続しないなら5555とすれば良い。多くの文献は5555で記述されている。
 
・Wi-Fi接続の実行
 adb connect IPアドレス:ポート番号

 ※この時端末は指定されたIPアドレスでWi-Fi接続している事。
  前述のコマンドで指定したポート番号を指定する事。

2017/8/18 20:03  [2048-58]   

その2:端末の状態確認、ログ取得について

当たり前ですが、adbコマンドを受け付ける端末が正常に接続されている前提です。
端末が未接続の場合は下記エラーメッセージが出力されます。
error: no devices/emulators found

・端末の接続を待つ
 adb wait-for-device

 ※一連のadbコマンドを連続実行する場合はバッチファイルの最初の方に記述します。
  これを記述しておけば端末が接続されない限り次のadbコマンドは送信されません。
  私はバッチファイルを起動してから端末接続を行うので、必ず記述します。
  他には下記のケースでバッチの起動タイミングを気にする必要がなくなります。
   端末の接続に若干時間の掛かるWi-Fi接続の場合
   USB接続でも端末側で接続承認を行う場合

・端末の充電状態を解除
 adb shell dumpsys battery unplug
 
 ※USB接続の場合は微弱ながら充電状態になります。
  電池残量が100%に近い時はバッテリーログが初期化される事があるので、それを防げます。
 
・端末の充電状態を元に戻す
 adb shell dumpsys battery reset
 
 ※解除をした場合は必ず戻す必要があります。
 

・端末の状態を確認する
 adb shell dumpsys <サービス名>
 
 ※サービス名無しでも出力されますが、大量に出力されるので画面のみでの確認は不可能です。
  サービスを指定した場合でも量が多い事もあるので出力結果はファイルにリダイレクトした方が良いです。
  
  指定を試してはいませんが、Android6の時にdumpsysに出力されたサービス名は121個ありました。
  未指定で出力された中ではDUMP OF SERVICE xxxxx: の形式(xxxxxがサービス名)で始まる部分です。
  
・端末のログを出力する
 adb shell logcat -<オプション>
  
 ※オプションを未指定の場合はキャンセルするまでログの出力が継続されます。
  オプションは数多くありますが、私が使用する事が多いのは下記です。
  
  -d ログを出力して終了する
  -b <バッファ名> 出力するバッファを指定する。
   バッファ名は下記及びallが指定出来ます。(内容は開発者用のサイト記述をほぼ直訳…意味が…)
    main メインログバッファです。システム及びクラッシュログメッセージは含みません。
    sysytem システムログバッファです。
    radio 無線及び電話関連のメッセージが含まれます。
    events バイナリのイベントバッファメッセージの解釈結果を表示。
    crash クラッシュログバッファです。

  ※-bオプションが未指定の場合はmain、sysytem、crashの3バッファが出力されます。
   但し、crashバッファは通常は空です。

2017/8/19 23:25  [2048-60]   

その3:端末の操作について

これは目的によって色々あると思いますが、私がログ採取の為にバッチで実行している事を中心に書きます。

・スリープを解除する方法
 これにはいくつか方法がありますが、実際にスマホ本体でスリープ解除する時と同じ事を実行すれば良いのです。
 通常利用では指紋認証で解除すると思いますが、キー操作では電源ボタンで解除されます。
 但し、この場合はロック状態のままになります。
 
 キーの遠隔実行には下記コマンドを使用します。
 adb shell input keyevent xxxxx
  xxxxx部分に実行したいキーを指定する
  
 電源ボタンは、KEYCODE_POWERです。
 KEYCODE_POWERの代わりに26を指定しても良いです。
 すでにスリープ解除されている状態で実行すると当然ですが画面が消えます。
 
 ボタン操作ではないですが、KEYCODE_WAKEUPとしても良いです。値は224
 KEYCODE_POWERとの違いは、すでにスリープ解除されている場合には何も起こりません。
 
 g07には存在しませんがメニューボタンを押すとスリープが解除されPIN入力画面になります。
 メニューボタンは、KEYCODE_MENU(または82)です。
 物理キーはありませんが有効です。
 
・キー入力
 前述のコマンドと基本は同じです。
 例えばPIN入力の場合は下記の様に書きます。
  adb shell input text pppppp
  adb shell input keyevent ENTER
   ppppppがPINで2行目で実行キー

・タップ
 adb shell input touchscreen tap xxx yyy
  xxx yyyが座標です。
  スクリーンショットをPC上の画像処理ソフト(座標表示が可能なもの)で確認します。
  実際には座標値-1が正確な指定値のようです。
  g07の場合に指定可能な値の範囲はxは0〜1079、yは0〜1919です。
・スワイプ
 adb shell input swipe x1 y1 x2 y2
  座標1(x1 y1)を座標2(x2 y2)の位置まで移動
  例 下方向に100動かす場合
   adb shell input swipe 100 200 100 100
    x1とx2は有効な範囲であれば良いです。
    y1とy2も有効な範囲で差分が100になれば良いです。
    
・スクリーンショット
 adb shell screencap -p <保存場所と保存名>
  g07デフォルトの保存場所
   /storage/sdcard0/Pictures/Screenshots/
  SDカード
   /sdcard/
  保存名は任意の値で構いませんが、PCへ移動するなら同じ名前を指定する必要があります。
 例 本体にscreen.pngで保存する
  adb shell screencap -p /storage/sdcard0/
Pictures/Screenshots/screen.png
  
・ファイルをPCへコピーする
 adb pull <保存場所とファイル名> <PC上の保存場所とファイル名>
 例 本体に保存したscreen.pngをPCのDドライブ直下のpictureフォルダへコピーする。
 adb pull /storage/sdcard0/Pictures/Scree
nshots/screen.png d:d:\picture\screen.pn
g
 
・ファイルを消す
 adb shell rm <保存場所とファイル名>
 例 本体に保存したscreen.pngを消去する
 adb shell rm /storage/sdcard0/Pictures/S
creenshots/screen.png

2017/8/26 22:11  [2048-62]   



がんばれg07

タグ:

気付けば購入後半年以上経過しました。
当初の目的(ナビ通信用とガラケーの代り)は達成しています。
また、勉強道具(遊び?)としても活躍しています。

今まで設定メニューのバックアプとリセットにあるデータの初期化は何度かやりました。
ただ、個人的には特に問題が無いならやらない方が良いと思っています。
何故なら良くも悪くも端末の状態が変化するからです。

私の場合は、初期化によってFOMA1枚運用が出来なくなりました。
これが正しい状態なのかも知れませんが、利便性が悪化したのは確かです。

確かに、トラブル時にメーカーサポートが初期化による変化を確認すると思います。
初期化命みたいな人も居ますけど、責任の取れない素人が第三者に初期化を勧めるのはどうなんですかね…

で、前置きはこれくらいにして…

上記の初期化とは別にファクトリーリセットがあります。
名前は知っていましたが、その手順の画面をネットで見て、若干ハードルが高いのか?と思っていました。

先日、時間があったのでトライしてみました。

電源OFF状態から、ボリュームUP+電源ボタンで英文のメニューが出ます。
DOWNだと中文らしいですが未確認です。

メニューから「wipe data/factory reset」を選択(ボリュームキーで移動し電源キーで確定)
次メニューで「Yes --delete all user data}を選択
終了したら、「reboot system now」を選択

これで再起動します。
再起動後は通常の初期化と同じ?(通常の初期化後を覚えてないw)です。

手順が少し違うだけですが、内部動作も違うのですかね…
と、思いましたが、状態が変化しました。

使うつもりは無いですが、テザリング不可が可能になりました。
時系列的にはこんな感じです。

・Android7化
 問題無しを確認
・初期化
 FOMA1枚運用不可に
 テザリングも不可(以前が可能だったかは不明)
・ファクトリーリセット
 テザリング可能
 
ここまでは良いのですが、ファクトリーリセット前後でログの出力量が大幅に変化しました。

全て深夜3時台の値(出力件数)ですが、まだ3日間ですが以下の通りです。
ファクトリリセット前  203件
ファクトリリセット後1  451件
ファクトリリセット後2  421件
ファクトリリセット後3  616件

ファクトリリセット後に倍増し、3日目だけは3倍になりました。
詳細の差異は比較中です。

2017/8/12 16:25  [2048-44]   

重要度毎の件数の内訳です。

リセット前の203件中の2件は重要度Dだったので201件で比較しました。
タグは下記の9件のみで総件数の多い順に列記します。

1. ccci_fsd(1)
2. Sensors
3. ActivityManager
4. ReceiverController
5. Accel
6. GCoreUlr
7. SQLiteDatabase
8. MPlugin
9. NetworkScheduler

それぞれの件数は、以下の通りです。

前   40,90,44, 2,15,10, 0,0,0
後1 372, 0,44,14, 0, 0,18,2,1
後2 362, 0,44,14, 0, 0, 0,1,0
後3 386,90,44,70,15,10, 0,1,0

リセット後に1番件数の多いccci_fsd(1)は以前も書いたようにSIMに関連するタグです。
FOMA1枚運用ができなくなったので、現在の運用は下記になっています。
 SIM1 : OCNデータ(未契約)、設定で無効
 SIM2 : FOMA音声
 
リセット前後で10倍近い値になるのはチェック頻度が短くなっているのでしょうか?
ちなみに、Android6の時(FOMA1枚運用)を確認したら30件前後でした。
この時は仕様上は許されない1枚運用なので出力は仕方ないですが、Android7では2枚運用なので、件数が増加するのは不思議な感じもします。
データ用SIMを無効設定にしている為なのか、そもそも通信可能なSIMにしないとダメなのかは、時間のある時にでも確認してみます。

Sensorsはリセット前とリセット後3日目で全く同じ内容が出力されています。
何故だ??? と思いましたが、基本に立ち返って考え仮説を立てました。

仮説
 全日とも端末が未使用(スリープ状態)で安定している同じ午前3時の値を使っている。
 しかし、DOZEに入ったタイミングは不一致だと思う。
 だから、定期的の訪れるメンテナンスウィンドウ(※)が訪れるタイミングも違うはず。
 たまたま、メンテナンスウィンドウが訪れた時のみSensorsが出力されている。
 ※保留された通信が一時的に解除されるタイミング

ログを追いかけてみましたが、仮説は否定されました。(と、思いました)

 メンテナンスウィンドウは1時間、2時間、4時間、6時間の間隔で発生するはず。
 メンテナンスウィンドウが開いている時間は短いはず。
 したがって、メンテナンスウィンドウで発生するなら、一つの時刻周辺に集中しているはず。
 
ところが、前も後3も集中している形跡はありません。
従って、仮説は否定されたと思ったのですが、Android7になってDOZEが変わったことを思い出しました。

Android6のDOZEにおけるメンテナンスウィンドウは前述のとおりです。
しかし、Android7では従来(深いDOZE)に加えて浅いDOZEがあり、メンテナンスウィンドウも短い間隔で発生するはず。

ログを確認すると、4分間隔でSensorsが出力されていました。
理由は不明ですが、前と後3だけが浅いDOZEだったのかも知れません。
別の時間帯の状態も確認すれば深いDOZEが発生しているなどの確認ができるかも知れません。
大変なので今は止めておきます。

次のActivityManagerはすべて同じ件数になっています。
ログを確認するとリセット後は正確に15分間隔で発生しています。(0分、15分、30分、45分)
リセット前は15分が18分にずれている以外は全く同じ時刻です。
ずれた理由は気になりますが、とりあえず変化なし(リセットは無関係)です。

疲れたので、一旦ここで中断します。

2017/8/12 17:48  [2048-45]   

定点観測と言う訳でもありませんが、4日目の午前3時の状況を取得しました。
新しいタグ(BatteryStatsService)が出力されていましたので、3日目までも含め再掲します。

1. ccci_fsd(1)
2. Sensors
3. ActivityManager
4. ReceiverController
5. Accel
6. GCoreUlr
7. SQLiteDatabase
8. MPlugin
9. BatteryStatsService
10. NetworkScheduler

※ソートの関係で9番目に挿入

それぞれの件数

前   40,90,44, 2,15,10, 0,0,0,0
後1 372, 0,44,14, 0, 0,18,2,0,1
後2 362, 0,44,14, 0, 0, 0,1,0,0
後3 386,90,44,70,15,10, 0,1,0,0
後4 392,90,44,68,15,10, 0,1,1,0

4日目は3日目とほぼ同じ結果になりました。

2017/8/13 07:41  [2048-46]   

Sensorsの内訳を再確認してみました。

正確に4分毎に同じ内容が繰り返されています。

handleToDriver handle(0)
handleToDriver handle(0)
new setDelay handle(0),ns(20000000)m, e
rror(0), index(2)
sensor 0 go to common batch
handleToDriver handle(0)
handleToDriver handle(0)

その結果、6件×15回(60分/4分)=90件となっています。

ざっくりと、センサー0(何かは不明)が発端で記録されているという事でしょうか?

2017/8/13 08:39  [2048-47]   

次のReceiverControllerは出現頻度が大きく変化しています。
リセット前はほぼ30分毎に、リセット後2日間はほぼ5分毎に発生してます。
3日目と4日目はほぼ毎分発生と頻度が急激に増加しています。

全てのメッセージは下記です。
filterReceiver() ignored with null actio
n

直訳するとfilterReceiverは空動作で無視されましたですかね…

何かが発生したけど結果として無視のようですが、「何か」が気になりますね。
そして、その頻度が増えた様に見えるのも気になります。

AccelはSensorsと同じ発生頻度で、正確に4分毎に発生しています。

メッセージも全て同じです。
ACC batch: handle:0, en:0,samplingPeriod
Ns:20000000 maxBatchReportLatencyNs:0

AccelはAccelerationの事でしょうか?
メンテナンスウィンドウの度に加速度センサーの状態をチェックしているって事?

GCoreUlrは出現しているリセット前、リセット後3日目、4日目とも、ほぼ同じ内容です。
これは位置情報に関するタグの様なので、端末の位置情報OFFにした※為かも知れません。

※4日目の前にはOFFにした記憶あり、その他は不明。
 通常はOFFですが、QZS捕捉確認でONにしたかも知れません。
 ログと同時に取得している設定の電池グラフで2日目にはGPSの項目がありました。
 グラフ描画はほぼ無いので、ログ取得時の状態は不明です。

ちなみに、元のログ(午前3時以外も含む全体)を見たら1時間毎に出現していました。

2017/8/13 13:55  [2048-48]   

5日目の午前3時の状況を取得しました。
比較の為に4日目までの件数も併記します。

1. ccci_fsd(1)
2. Sensors
3. ActivityManager
4. ReceiverController
5. Accel
6. GCoreUlr
7. SQLiteDatabase
8. MPlugin
9. BatteryStatsService
10. NetworkScheduler

それぞれの件数

前   40,90,44, 2,15,10, 0,0,0,0
後1 372, 0,44,14, 0, 0,18,2,0,1
後2 362, 0,44,14, 0, 0, 0,1,0,0
後3 386,90,44,70,15,10, 0,1,0,0
後4 392,90,44,68,15,10, 0,1,1,0
後5 413,84,44,68,14,20, 0,1,1,0

5日目は4日目と近い結果なのですが、微妙な差が出ました。

今までは4分間隔で出力されていたSensorsとAccelの件数が減っています。
ログを見ると2度間隔にずれが生じていて、4分が若干長くなっているところがありました。
その結果、最後の分が4時台にずれ込んでいました。

再度、その他の日のログも確認したところ、同様のずれが発生していることが分かりました。
ずれの発生時以外は秒の単位まで正確に4分間隔なのでずれには何か原因があると思います。

もう一つ、今までは1時間に1回だったGCoreUlrが2回出力されています。
前後の時間帯も確認したら、2時台に出力が無い事が分かりました。
出現時刻は以下の通りです。

1:28
(2時台無し)
3:10
3:26
4:28
5:26
6:29

2時台の分が3:10にずれたのでしょうか?

1時より前は位置情報をONにしてQZSの捕捉を試みていた為なのか記録がありません。
相変わらず捕捉できていませんが…

2017/8/14 08:25  [2048-49]   

GCoreUlrまでで出現頻度がそれなりのタグは終わりです。

SQLiteDatabaseについてはリセット後1日目のみ出現しているので例外※と考えることもできます。
しかし、念のため前後の時間帯を確認してみました。
※機種やOS等に共通した特定の原因ではなく、突発的な要因で発生の意味

SQLiteで始まるタグはSQLiteDatabaseが圧倒的に多いのですが他にも2種(計3種)ありました。

SQLiteDatabase
SQLiteLog
SQLiteCastStore

たまたま午前3時台に出力されていなかっただけで他の時間帯に出力された例もありました。
概ねの傾向として、リセット前より出現頻度は大幅に減少しています。

ログが取得できている範囲でですが、リセット後2日目を最後にSQLiteDatabaseは出力されていません。

厳密には重要度Eの出力がないという意味で重要度Dで下記の2種が出力されています。
 beginTransaction()
 endTransaction()

文字通りDBに対する処理開始と終了の意味ですね。
正常に処理ができていると解釈しました。

何かの機能やアプリが正常に機能しないのは、このDB処理が失敗しているって事なのかもしれません。

2017/8/14 13:21  [2048-50]   

6日目の午前3時の状況を取得しました。
但し、一つだけ条件を変えてみました。

変更した条件
 SIM1の設定を有効に変更
 
以前書いた様にSIM2のFOMA利用の為のダミーで、通常は無効にしています。
SIM関連のログが出ていたので、変化する(減るのか?)と推測していました。

結果は下記の通り

前   40,90,44, 2,15,10, 0,0,0,0
後1 372, 0,44,14, 0, 0,18,2,0,1
後2 362, 0,44,14, 0, 0, 0,1,0,0
後3 386,90,44,70,15,10, 0,1,0,0
後4 392,90,44,68,15,10, 0,1,1,0
後5 413,84,44,68,14,20, 0,1,1,0
後6 431,90,44,71,15,20, 0,1,1,0

昨日まで出現していたタグ部分だけを比較するとほぼ変化無しでした。
しかし、新規のタグが出現しました。

昨日までのタグ

1. ccci_fsd(1)
2. Sensors
3. ActivityManager
4. ReceiverController
5. Accel
6. GCoreUlr
7. SQLiteDatabase
8. MPlugin
9. BatteryStatsService
10. NetworkScheduler

新規に出たタグと件数

MAL-RDS 281件
SearchServiceStarter 15件
MAL-SIMMNGR 6件
PlayCommon 4件
RequestManagerImpl 3件
Finsky 1件

通信契約の無いSIM1を有効にするとエラーログが増える様です。
まあ、冷静に考えれば使えないSIMを使って通信しようとするだろうから増えますよね。

別途、SIM1に通信契約のあるSIMを入れて変化を確認したいと思います。

2017/8/15 10:41  [2048-52]   

7日目の午前3時の状況を取得しました。
SIM1に通信契約のあるSIMを入れて確認しました。

当然、その結果はSIM関連のエラーが減るはずと予測したのですが、裏切られました。

結果(5日目までの出現タグの件数)は下記の通り

前   40,90,44, 2,15,10, 0,0,0,0
後1 372, 0,44,14, 0, 0,18,2,0,1
後2 362, 0,44,14, 0, 0, 0,1,0,0
後3 386,90,44,70,15,10, 0,1,0,0
後4 392,90,44,68,15,10, 0,1,1,0
後5 413,84,44,68,14,20, 0,1,1,0
後6 431,90,44,71,15,20, 0,1,1,0
後7 393,90,44,68,15,10, 0,1,1,0

若干の件数の変動はあるものの変化無しと言える結果です。
しかも、6日目に出現したタグと新たなタグも出ました。

5日目までの出現タグ

1. ccci_fsd(1)
2. Sensors
3. ActivityManager
4. ReceiverController
5. Accel
6. GCoreUlr
7. SQLiteDatabase
8. MPlugin
9. BatteryStatsService
10. NetworkScheduler

6日目の新規出現タグと6日目及び7日目の件数

MAL-RDS 281件,68件
SearchServiceStarter 15件,0件
MAL-SIMMNGR 6件,2件
PlayCommon 4件,1件
RequestManagerImpl 3件,0件
Finsky 1件,0件

7日目の新規出現タグと件数

NativeCrypto 4件
GoogleTagManager 4件
GeofenceHelper 1件


6日目に出現したタグは通信SIMを有効にする事で出現する事から、データー通信に関わるタグと推測出来ます。
7日目は通信可能SIMに変更したので件数(エラー)が減ったと言う事でしょうか?

今更ですが、ログ上のSIMスロットは1と2では無く、0と1の様です。
MAL-RDSで出力されたメッセージ無いにsim:1の記載がありました。
ccci_fsd(1)の1もSIM2を示すのだと思います。

共通項目のSIM関連の件数も変化が無い事から、SIM2のFOMA関連と推測しました。
FOMAをSIM1に変更しとccci_fsd(1)の1が0に変われば、確認出来ます。

最後に、以前から感じていたのですが、出力されるログの重要度が本当に正しいのか怪しいです。
メッセージを見るとEでは無く、DやIでも良いと思える内容もあります。
勿論メッセージは開発者が判別出来る範囲で簡略化されているので絶対とは言えません。

何か明確な不具合があれば、それに関連しそうなログを追いかける事も可能ですが、今の状態だと意味が無さそうです。
なので、リセット後の1週間を良い機会として一旦終了します。

2017/8/16 09:17  [2048-53]   

書き忘れましたが、SIM1に入れたSIMのアンテナピクトが異常に低いです。
元々FOMAも低めなのですが、それ以下を示します。

FOMA  2〜3
データ 0〜2

それがログにも現れている可能性はあります。
SIM設定は標準アプリ及び設定メニューで行っていますが、再確認してみます。

2017/8/16 09:27  [2048-54]   

データ通信用のSIMは日常はiPhoneに入れています。
g07で受信レベルが異常に低く見えるので、iPhoneの状態を確認しようとしました。

しかし、何故かアンテナピクトが表示されていない。
調べる間もなく用事で出掛けましたが、外出先でも通信は出来ていました。

帰宅してから色々いじっていたらデータ専用SIMだけど音声もONにしたら表示されました。
改めてググって見たらiOS10の既知情報だったのですね…

iPhoneでも電波強度は低めでした。
自宅の場所が良くないみたいです…(>_<)

g07は更に感度が良くないので4Gでは使えないかも…使ってないですが…

2017/8/16 18:36  [2048-55]   

止める予定でしたが、一つだけ確かめたい状態があったので再度取得しました。
同様に午前3時台の状態です。

変更した条件は、全てのSIMを除く事です。
一般的にはSIM無しの状態は電池消費を増大させると言われている様なのでログ上も変化があるはずです。

SIM無し状態での結果の推測としては、下記のいずれかだと思いました。
 SIM関連のエラーが出なくなる
 SIMが無い事によってSIMを探す為にエラーが増大する
 
しかし、いずれも外れで、状態に殆ど変化は無いでした。 何故だ…

出現タグ(5日目まで共通のみ)

1. ccci_fsd(1)
2. Sensors
3. ActivityManager
4. ReceiverController
5. Accel
6. GCoreUlr
7. SQLiteDatabase
8. MPlugin
9. BatteryStatsService
10. NetworkScheduler

出現件数

前   40,90,44, 2,15,10, 0,0,0,0
後1 372, 0,44,14, 0, 0,18,2,0,1
後2 362, 0,44,14, 0, 0, 0,1,0,0
後3 386,90,44,70,15,10, 0,1,0,0
後4 392,90,44,68,15,10, 0,1,1,0
後5 413,84,44,68,14,20, 0,1,1,0
後6 431,90,44,71,15,20, 0,1,1,0
後7 393,90,44,98,15,10, 0,1,1,0
後8 376,90,44,99,15,10, 0,1,1,0

※7日目のReceiverControllerの件数にミスがありました。上記は修正済み。

※6日目及び7日目に出現したダグは8日目には記録されませんでした。

5日目までのSIMの状態
 SIM1:通信用ダミー(無効化)
 SIM2:FOMA(音声専用)
 
6日目のSIMの状態
 SIM1:通信用ダミー(有効化)
 SIM2:FOMA(音声専用)
 
7日目のSIMの状態
 SIM1:通信用(音声及びSMS無し)
 SIM2:FOMA(音声専用)

8日目のSIMの状態
 SIM1:無し
 SIM2:無し
 

データ通信用SIM(ダミーでも)を有効にすると出現するタグは4G通信関連だと思います。
しかし、共通して出現しているccci_fsd(1)はSIM2のFOMA(3G)関連だと推測していましたが違う様です。

もう一つ不可解なのは、通信SIMが有効でもSIM無しでもReceiverControllerがほぼ同じ(計測期間で最大)な事です。
前にも書きましたが、全て同じメッセージfilterReceiver() ignored with null actio
nです。

関連情報を探してググっていて分かりました。
どうやらnullは単に何も無いという事では無いようです。

本来何らかの値が返されるはずの所で何も返されないので異常かも?と言う意味でログ出力している感じですね。
開発者はnullの扱いには苦労するみたいです。

それにしても有効なSIMでもSIM無しでもほぼ同じ頻度でnullが発生するのは何故なのでしょうか?

2017/8/17 11:07  [2048-56]   

もう一つ確認…と思って位置情報をONにして状態の変化を…再確認するつもりでしたが、失敗(>_<)

就寝前に位置情報はONにしたのですが、単にそれだけではダメだったようです。
ログの結果は前日と殆ど同じでした。

出現タグ(6,7日目を除く共通)

1. ccci_fsd(1)
2. Sensors
3. ActivityManager
4. ReceiverController
5. Accel
6. GCoreUlr
7. SQLiteDatabase
8. MPlugin
9. BatteryStatsService
10. NetworkScheduler

出現件数

前   40,90,44, 2,15,10, 0,0,0,0
後1 372, 0,44,14, 0, 0,18,2,0,1
後2 362, 0,44,14, 0, 0, 0,1,0,0
後3 386,90,44,70,15,10, 0,1,0,0
後4 392,90,44,68,15,10, 0,1,1,0
後5 413,84,44,68,14,20, 0,1,1,0
後6 431,90,44,71,15,20, 0,1,1,0
後7 393,90,44,98,15,10, 0,1,1,0
後8 376,90,44,99,15,10, 0,1,1,0
後9 386,90,44,98,15,10, 0,1,0,0

※9日目は6日目及び7日目に出現したPlayCommonが1件出力されました。
 

5日目までのSIMの状態
 SIM1:通信用ダミー(無効化)
 SIM2:FOMA(音声専用)
 
6日目のSIMの状態
 SIM1:通信用ダミー(有効化)
 SIM2:FOMA(音声専用)
 
7日目のSIMの状態
 SIM1:通信用(音声及びSMS無し)
 SIM2:FOMA(音声専用)

8,9日目のSIMの状態
 SIM1:無し
 SIM2:無し
 
データ通信用SIM(ダミーでも)を有効にすると出現するタグは4G通信関連だと推測していました。
しかし、PlayCommonはSIMの状態(4Gとか3G)とは無関係に出力されるタグの様です。
 メッセージを再確認したところ、GooglePlay関連のタグでした。
 そして、全ての日で内容が異なる事が分かりました。
 
6日目
 [1281] com.google.android.play.a.g.a(480
): Failed to upload logs: java.net.Socke
tTimeoutException: timeout

7日目
 [521] com.google.android.play.a.g.a(466)
: Failed to connect to server: java.net.
SocketTimeoutException: connect timed ou
t
 
9日目
 [103] PlayEventLogger.uploadLog: Failed
to connect to server: java.net.UnknownHo
stException: Unable to resolve host &quo
t;play.googleapis.com": No address
associated with hostname
 
(↑たぶんこれも変なところで改行されてるのだろうな…)

位置情報についてはログ取得後に衛星情報の確認を行いましたが、位置取得が出来ていませんでした。
暫く放置した結果、位置取得が出来るようになったので、今晩再度ログ採取してみます。

2017/8/18 08:51  [2048-57]   

昨日の設定(位置情報ON)のままで再度ログを採取

結果は、ほぼ同じ…単に位置情報ONだけでは変化しないようです。

出現タグ(6,7日目を除く共通)

1. ccci_fsd(1)
2. Sensors
3. ActivityManager
4. ReceiverController
5. Accel
6. GCoreUlr
7. SQLiteDatabase
8. MPlugin
9. BatteryStatsService
10. NetworkScheduler

出現件数

前   40,90,44, 2,15,10, 0,0,0,0
後1 372, 0,44, 14, 0, 0,18,2,0,1
後2 362, 0,44, 14, 0, 0, 0,1,0,0
後3 386,90,44, 70,15,10, 0,1,0,0
後4 392,90,44, 68,15,10, 0,1,1,0
後5 413,84,44, 68,14,20, 0,1,1,0
後6 431,90,44, 71,15,20, 0,1,1,0
後7 393,90,44, 98,15,10, 0,1,1,0
後8 376,90,44, 99,15,10, 0,1,1,0
後9 386,90,44, 98,15,10, 0,1,0,0
後10 400,96.44,100,16,10, 0,1,1,0

ほぼ4分周期で出現するSensorsとAccelが1周期分多いです。
これはちょうど0分から記録されたので、たまたま16回目が記録されただけのようです。

これ以上続けても意味が無さそうなのでSIMを通常運用に戻します。
あと確認するとしたらSIM有りで位置情報ONくらいかな…

2017/8/19 11:04  [2048-59]   

SIM有りで位置情報ONのログを取得しようとして、失敗しました。

昨夜はAndroiTS GPS Testで位置情報が取得できていることを確認したのですが、アプリを終了したつもりでミスしてました。
結果、動作したままでログ取得となってしまいました。

昨日までは600件台だったのですが、なんと7285件を記録してしまいました。
但し、5日目までの共通タグの件数を拾うと下記の様になりました。

1. ccci_fsd(1)
2. Sensors
3. ActivityManager
4. ReceiverController
5. Accel
6. GCoreUlr
7. SQLiteDatabase
8. MPlugin
9. BatteryStatsService
10. NetworkScheduler

前   40,90,44, 2,15,10, 0,0,0,0
後1 372, 0,44, 14, 0, 0,18,2,0,1
後2 362, 0,44, 14, 0, 0, 0,1,0,0
後3 386,90,44, 70,15,10, 0,1,0,0
後4 392,90,44, 68,15,10, 0,1,1,0
後5 413,84,44, 68,14,20, 0,1,1,0
後6 431,90,44, 71,15,20, 0,1,1,0
後7 393,90,44, 98,15,10, 0,1,1,0
後8 376,90,44, 99,15,10, 0,1,1,0
後9 386,90,44, 98,15,10, 0,1,0,0
後10 400,96.44,100,16,10, 0,1,1,0
今回  30,90,44,104,15, 0, 1,2,4,0

ccci_fsd(1)が劇的に減少(リセット前と同じレベル)した以外はほぼ同じレベルでした。
BatteryStatsServiceが多いのは、バッテリー残量が少ない為と推測しましたが、正しいかどうかは不明です。

今回、新規に出現したタグが件数激増の原因でした。
 mpe 6670件

メッセージは下記の2種類のみです。
mnl_sendto_: [mnld2] ERR: sendto dest=[
/data/_mnl/mnl2] len=24 reason =[No such
file or directory]
mtk_gps_mnl_trigger_: [MNL2MPE]Send to
MPE failed, No such file or directory

これはAndroid7へアップデート直後にも出ていたタグで正確に毎分60回記録されます。
どうやら、AndroiTS GPS Testの動作によって出力されていると考えるのが自然な様です。

もう一つ面白い事が分かりました。
mpeが出力されている期間は何故かccci_fsd(1)は出力されていません。
関連性があるのかどうかは不明です。

ただ、mpeは3:55を最後に朝に端末を起動するまでは出力されていません。
ccci_fsd(1)の件数が少ないのは殆どの時間帯でmpeが出力されていたからの様です。

もしかしたら、DOZEによってバックグランドのAndroiTS GPS Testが停止したのかも知れません。
端末起動時には、AndroiTS GPS Testは起動していてmpeも再度出力されていました。

結局、何も分かっていませんが、この程度のログ件数は、この端末の場合は通常と考える事にします。

2017/8/20 11:15  [2048-61]   



がんばれg07

タグ:

ちょっと強引かも知れないけど…
再起動直後にデバッガーが起動してログ採取してるって事にして、少しログ自体を確認してみました。

起動直後の1〜2分間は全ての重要度が出力されていますが、それ以降はほぼEのみになっています。
これはアップデート前とは大きく事なりますが、無駄な出力が減ったという意味では良い事です。

問題なのは、その1〜2分間のEの数も桁違いに多い事です。

最初はデバッガーの起動に関わる記録が64bitと32bit分があり、その後に最初のEが出力されてます。

AEE_AED : Can't remove file /sdcard/mtkl
og/aee_exp/temp: No such file or directo
ry
AEE_AED : Can't remove file /data/aee_ex
p/temp: No such file or directory
AEE_AED : Can't remove file /storage/ext
_sd/mtklog/aee_exp/temp: No such file or
directory

ログを削除しようとして見つからないって記述です。
全てtempの様なので無いのが正常なのかも知れません。

次に出現するのは、下記でそれ以降の [mTEE] (7件)は全てEになっています。
[mTEE] : [ERROR]: TEEI Daemon VERSION
[tag.base.dbg.2.5.1]

TEEはTrusted Execution Environmentの略の様で直訳すると「信頼出来る実行環境」
mはmediatekの意味なのかも…

それにしても、「信頼出来る実行環境」がエラーってダメなのでは???
なんか、ログを追いかける気力が…一旦中断します。

2017/8/1 23:15  [2048-40]   

logcatとBatteryStatsの両方の記録を保持(初期化させない)しようとしてるけど上手くいかない。
充電と放電(ゲームアプリ起動放置)をバランス良くしてれば可能なはずだけど…

結局、放置して満充電か電池切れになってしまいます。
満充電でも今のところログは継続して記録されているので、自動再起動はしていない感じです。

電池切れ後の再起動では、必ず最初の方は全く同じログが残ります。

以前は夜間に放置してたはずの時刻に同じログが残っていたので再起動した可能性は否定出来ないです。

と言う事で、充電のまま放置してログの状況及び再起動したかどうか確認します。
再起動すると指紋認証ではなくPIN入力を求められるので、それで判断します。
再起動の条件が分かると良いのですが…

忘れて、ログ採取しない様にしないと…
バッチに組み込んだADBコマンドでPIN入力するので判断出来なくなるので。

2017/8/4 17:32  [2048-42]   



がんばれg07

タグ:

従来の使用状態のままでアップデートした。
Chromeの更新で少し迷った以外は問題無さそうでした。
ただ、満充電時にLED消灯しない状態も従来通りだったので念のため初期化してみました。

結果、大きな問題(私にとって)に直面しています。
ただ、仕様通りと言えばその通りなのですが…。

問題点
 FOMA通話専用SIMのみで使用可能な状態に出来ない

DSDS設定した場合(データ通信可能なLTE対応SIMとの併用)やダミーSIM利用では使用可能です。

Android6ではLTE対応SIM(契約済み、ダミーとも)で設定後にLTEを抜いてもFOMAは使用可能でしたが、現状では使用可能状態に戻せなくなりました。

端末初期化前はFOMAのみで使用可能でした(Android6の状態を引き継いでいた)ので初期化によって状態が変化したと考えています。

全ての組合せは未確認ですが、今のところ確認したのは2パターン(OCNはダミー)

SIM1 FOMA、SIM2 OCN
SIM1 OCN、SIM2 FOMA

どちらもSIM管理アプリで設定後にアンテナピクトを確認し、docomoからのSMS(正常に繋がったとの通知)も受信しました。
尚、SIM管理アプリでダミーSIMを使用不可に設定した状態でもFOMAは利用可能です。

Android6と7の違いで気付いたのは、設定後にFOMAのみで再起動した時のメッセージです。

6では、SIM構成が変更されたの再設定せよとの趣旨のメッセージだったはず
7では、SIMカードの変更完了、タップしてセットアップとの記述

そして、設定アプリのSIMカードの設定状態を見ると、
6では優先SIMに取り除いたダミーの設定が残っていた
7では全てがFOMAに変更されている

当然、この状態なら使用出来ませんね…SDカードを諦めてダミーを使うしかなさそうです。

ちなみに、満充電時のLED消灯は充電中なので確認出来ていません。

2017/7/26 13:21  [2048-28]   

亜都夢 さん  

2017/7/28 23:58  [2048-29]  削除

まずは充電時のLEDですが、消えてくれません。
これはバージョンアップ前からなのでアップデートが原因ではありません。

一応アップデート前後のログは取得してあるので、そのうち比較してみます。

ただ、これを書く直前にログを採取したのですが、重大?なミスをした事を発見しました。
初期化によって、開発者向けオプションも初期化され、デバッグモードも解除、ログバッファもデフォルトの256KBに戻っていました。
再度、最大の16MBに設定し直しました。

では、本題…
本日夕方からQZS(日本版のGPS衛星)の捕捉を試みました。
使用したアプリはAndroiTS GPS Test Freeです。
結果はNGでした。

バージョンアップ前は捕捉出来ていました。
但し、QZS自体が3号機の打ち上げも予定されていて必ずしも安定して受信出来るとは限らない状況のようです。

そこで、ログを確認してみました。
バッファが小さかったので20分間しか残っていませんでしたが、GPS関連と思われるエラーが多数出力されていました。

エラーは下記の2行で正確に1秒間に1回ずつ(約20分間で毎分60回)出力されています。

mnl_sendto_: [mnld2] ERR: sendto dest=[/

data/_mnl/mnl2] len=24 reason =[No such

file or directory]

mtk_gps_mnl_trigger_: [MNL2MPE]Send to M

PE failed, No such file or directory

これが何を意味するのかは正確には不明ですが、データの保存先ディレクトリが存在しない事によるエラーに見えます。

これがQZS捕捉と関係があるかどうかは不明です。

アップデート前の状況は次回までに確認します。

2017/7/28 23:59  [2048-30]   

とりあえずGPS関連と思われる部分だけアップデート前のログを確認してみました。

まず、前回のログはメッセージ部分のみでタグは両方ともmpeでした。
OSバージョンが異なるので単純比較は出来ませんが、アップデート前にmpeタグは存在していませんでした。
但し、アップデート前はQZS捕捉テストをしていた訳では無いので、それが差異理由かも知れません。

細かくは精査出来ていませんが、アップデート前後のログに大きな傾向の差がある事が分かりました。

アップデート前はログの75%程度はデバック(重要度D)でしたが、アップデート後はほぼ全てがエラー(重要度E)です。
これは、エラー割合が上昇したという意味では無く、不要なログは出力しない様に変更されたと言う事だと思います。

実際に記録行数も大幅に減少しています。
尚、アップデート前のログはアップデート直前、アップデート後は本日朝のものです。

アップデート前
 記録時間 14分
 全体   約22万行
 エラー  約1万行

アップデート後
 記録時間 約4.5時間
 全体   約2900行
 エラー  約2800行

ここまでは良いのですが、アップデート後のログに一つ不可思議な事を発見しました。

前回記載時にログバッファの拡張を行ったのでこの程度の量であれば記録漏れは無いはずです。
しかし、記録されている期間が異常に見えます。

ログは常時記録され、バッファが足りなくなると古い物から上書きされます。
現状のログ数では上書きは行われないので、今朝のログは少なくともバッファ拡張以降全てが記録されていなければいけません。

しかし、ログはバッファ拡張のかなり前の1行と拡張後約3.5時間後から記録されています。
これが何を意味するのかは分かりませんが、何か問題が内在している可能性は否定出来ません。

もう一つ、満充電時のLEDが消灯しない問題を再確認していたところ、スリープ(画面消灯)しない場合がある事が分かりました。

念のため、充電していない状態で確認してみるとスリープするまでの時間が設定時間とは少し異なる(正確に計測していないので感覚です)気がします。

どちらの場合も、時間以外のスリープする条件が揃わない為だと思いますが、それが何かは不明です。

2017/7/29 08:47  [2048-31]   

ログを見ていて一つの仮説に行き着きました。

まずは、記録されたログですが、内容では無く記録時刻と件数ですが、だいたい下記の感じです。
Wはワーニング、Eはエラーの意味のはずです。

18:15  1件 W ※23:02に取得したログにはこの時刻の記録は無い
03:14  1件 W
03:15 1269件 Eが1199件
03:16  20件 E

 ※これ以降毎分0〜数十件(殆どE)が出力されている。
  3:28のみ193件の記録が有る

4時台から6時台は毎時200件強(殆どE)が出力されている。
DOZEモードに入った状態だと推測。

7時台前半で起動しているが、ログ数は若干増加が見られる程度。

ログの不可解な点
 18:15の1件から9時間も記録時刻に空白が存在する事
 明らかに3:15の記録数が多すぎる事
 23:02に取得した別のログでは18:15の記録が存在しない事

結論(仮説)
 何らかの理由でログが正常に記録されていない。
 記録されたログだけ見ても正しい判断は不可能。

って、これじゃ意味が無いですね…

3:15より後はほぼ同じ様なログ状態が続いているので、3:15に何か変化が起きた可能性も否定は出来ません。

ただ、3:28のログを見ると「イベントログに記録出来ない」、「データベースがオープン出来ない」等の記録が残っているので、正常に戻ったとは言えないようです。

後ほど再度ログを取得して状況の変化を確認してみます。

2017/7/29 16:57  [2048-32]   

何度かログ採取をしてみましたが、状況に変化無しです。

1.1件だけ時刻の離れたログ
 前回の例では18:15の1件

2.連続的に記録されはじめの最初に大量の記録
 前回の例では03:15の1269件

不思議なのは最初の1件の出現の仕方です。

確認の為、8:25から8:52まで数回ログ取得をしました。
ログは追記されるだけで、最初の1件は同じでした。

16:33に再度取得したところ、最初の1件を含め記録時刻が大幅に変わっていました。
しかし、記録時刻に共通点を見つけました。

8:25の状況
 1件目 14:51:19(前日)
 2件目 23:51:14(前日)
 3件目 23:51:15(前日)
 4件目 23:51:15(前日)
 5件目 23:51:19(前日)

16:33の状況
 1件目 05:18:03
 2件目 14:17:57
 3件目 14:17:58
 4件目 14:17:58
 5件目 14:18:03
 
5件目は1件目の正確に9時間後の時刻になっています。
記載していませんが秒未満も全く同じです。

もう一つ…詳細は割愛しますが、79行目まで記録時刻以外は全く同じに見えます。
ただ、内容は本体のログと言うよりはデバッガーの動作状況の記録に見えます。

特に9時間の謎の意味は何でしょうか?
JSTとGMTの処理が正常に行われていないって事でしょうか?

そもそもの問題として、アップデート前より大幅に少ないログしか取得出来ていません。
ログバッファは最大に変更していますが、正しく反映出来ていないって事なのかも…

不思議ちゃんが、ますます不思議な感じになってきました。

2017/7/30 18:19  [2048-34]   

あ…アイコン適当に選んでたらw

連続的に記録されはじめの最初に大量に記録されたログを確認してみました。

何らかの理由で記録時刻のみが置換され一括出力されたのかと疑いましたが、違う様です。

何故なら、この時だけ出力されているタグが多数存在するからです。
常時出力されているタグなら、他の時刻にも存在しないと説明が付きません。

2個前の8:15に記録された重要度Eの1199件の中で、10件以上記録されたタグだけで以下の通りです。
計806件(2件〜9件は計108件)

PermissionMonitor 239件
MAL-RILP 109件
MtkOmxVenc 80件
SoftOMXPlugin 64件
OMXNodeInstance 53件
OggExtractor 33件
MtkOmxVdecEx 33件
DrmMtkUtil/DrmUtil 30件
DrmMtkPlugIn 30件
MAL-SIMMNGR 29件
PhoneInterfaceManager 20件
TouchFilter 14件
CrashlyticsCore 14件
タグ無し 13件
Cta5File 12件
mtk_lbs_utility 11件
agps 11件
MAL-Daemon 11件

メッセージを確認してみないと断言は出来ませんが、正常では無い様に見えます。

疲れたので、内容の確認はそのうちに…

2017/7/30 21:33  [2048-35]   

今朝取得のログの状況も全く同じでした。

ログ自体が不正になっていると仮定して、一旦強制的にログ消去(adb logcat -c)しました。
再度ログ取得したところ、以前の状態(9時間離れた1件)は解消されたようです。

今日一日の状況を確認してみます。

2017/7/31 08:06  [2048-36]   

やっぱりダメでした。

帰宅後にログを採取、クリアしてから約12時間後です。
結果は以前と同じで、1件のログから9時間後から記録が続いています。

比較はしてませんが、たぶん79行目までは時刻以外は同じなのでしょう。

離れた1件と連続し始めのログはデバッガーに関わる内容っぽい…
今更ですがデバッガーが動くって何故?

ADB使うのでUSB接続時のデバッグは許可としてるけど、時刻的には無関係のはず…

開発中なら設定されたブレークポイントでデバッガーが起動って動作は理解出来る。
但し、一般論であってAndroidで同じ事をするかどうかは知らない。
仮にそうだとしても、リリース物はそんな設定しないよね…まさか、解除漏れなのか?

でも常時ログを吐いてるのだからデバッグモードが定常状態なのかな?
よく分かりません…(>_<)

以前とログの状態が違う事だけは確かで、明らかにエラーに見える記述も数多く出現してる。
やっぱり新しいOSは時期尚早だったのかな…

2017/7/31 23:11  [2048-37]   

もしかして、スリープ時に予期しない何かが発生し、デバッガーが起動してログを書き替えるのか?
と、推測しながら朝一にログ取得…

まさか…昨夜に確認したログに追記されています。
9時間離れた1件も同じ、それ以降の記録も同じ。

昨日までと異なる条件は…バッテリー残量?
記憶は曖昧だけど昨日以前は朝一番に満充電にしたくて充電してたかも…

あ、でも昨日昼間の状況は説明出来ない…充電はしていない状態でも同じパターンになった…
ただ、負荷の掛かる様な使い方はしていなかったので、バッテリー残量はMAXだった可能性はあるかな。

昨夜ログ採取した時点(帰宅直後では無い)では、充電したのか(記憶に無いw)100%でした。
前にも書いたけど、バッテリー状態のログ(Batterrystats)は100%になると消去されるので、昨日昼間の状況が分かりません…(>_<)

2017/8/1 08:27  [2048-38]   

気がついたら不定期でログ取得しようとPCとUSB接続して微充電状態で放置。
万一、満充電になるとバッテリーログが消えるので、念のため、ゲームアプリも起動したまま。

気がつくと画面消えてるので、スリープしたのか???って思ったら、電池残量0で落ちてた(>_<)
ゲームアプリの電池消費量が大き過ぎた(^_^;)

ちょっとだけ充電して起動後にログ採取。
電源落ちるとlogcat関連はクリアされるので初期状態が確認可能のはず。

結果、いつものログの状態と同じ…!
もしかして、いつも気がつかずに再起動(あるいはそれと同じ状態)になってたのか???

9時間前の1件も、何故か1件だけJSTではなくGMTで記録されただけだったみたい。
一応、その1件の時刻を今朝のログ(昨夜からの追記)で確認したけど、存在しない。

そう言えば、今朝ログ取得後にバッテリー残量少なくて落ちてた様な…今更?
BatteryStats確認したらシャットダウンが動いてた。

その時点(今回落ちる前に取得)でのlogcatを確認すると、再起動時にいつもの状態になっていました。

と言う事で、今のところ、勝手に再起動説が有力っぽい。

2017/8/1 13:58  [2048-39]   

PC接続での充電量<ゲームアプリの消費量の様なので、ゲームアプリ無しで忘れてたら満充電になってました(>_<)
当然、BatteryStatsはクリアされています。

でも、ログは継続して記録されています。
これは当然(仕様だと思う)のですが、満充電になった時が意図しない再起動のタイミングかと疑っていたので、ちょっと残念かも。

ログ上で満充電になったタイミングを確認したいけど、よく分からない…
BatteryStatsは記録開始したタイミングの時刻だけは分かります。
Daily stats:という項目に過去の記録開始時間の履歴も残ってるみたいです。

現在の開始時刻と過去記録時刻との間に満充電時刻があるはずだけど…あまり役に立たない。

仕方無いので順に遡って確認。
満充電時刻とは無関係だと思うけど、気になる記録が…当然Eです。
BatteryStatsService: power: Missing API

端末を放置(多分スリープ中)の間は、ほぼ5分間隔で出力されてる。
この意味は???BatteryStatsが正常に記録出来ていないって事?

もしそうなら、設定の電池表示は信じられないって事になるけど…

勉強するには(遊ぶには?)良いけど、通常使用(特に仕事用)はどうなの?って感じですね。

ちなみに、FOMA1枚運用が不可になってしまったので、別の機種の状況を確認したら…
ZenFone3はAndroid7でもFOMA1枚運用が出来る様なので、浮気しようかな…(^_^;)

2017/8/3 09:00  [2048-41]   



がんばれg07

タグ:

久し振りに…

6/27日版のファームウェアにアップデートしてみました。
今回の改善点は下記3点らしいです。

(1)スリープ復帰または接続圏外から圏内復帰時にWi-Fiがアクセスポイントをつかめない事がある問題を修正

(2)5GHzかつステルス設定にしているアクセスポイントにWi-Fiで接続できない問題を修正

(3)アドウェアと誤検知されるプラグインファイルを削除

ただ、自分の環境では前のファームでも1と2は問題はありませんでした。
3もESETでは誤検知しないので気にしてませんでした。

折角なのでログの比較を…と思ったら最近は取得していなかったので4/11版との比較
とりあえず、mainですが…

どちらも取得したのは21万行位ですが、記録時間が大きく異なります。
また、重要度の内訳数も若干違います。

4/11版 212,464行 18分間
 V:8,077行、D:149,128行、I:46,693行、W:453行、E:8,113行
6/28版 218,087行 2時間45分間
 V:7,433行、D:150,232行、I:48,228行、W:707行、E:11,487行

但し、例えばEの内容を確認してみると、エラーでは無く単なる情報に見える行が殆ど(新旧とも)なので、数の差は意味が無い気がします。

記録時間が長くなったのも、利用状況の差が不明なので、一概に安定したとも言い切れません。

某掲示板では相変わらず異常を訴える人が居ますが、本当にg07単体の問題なのか疑問です。

私は価格の掲示板への投稿は止めましたが、きっと問題の無いユーザは見に来ないし、殆ど書き込まないでしょうね。
それにしても相変わらずユーザ以外の方が多数を占める状況って、どうなんでしょう…

思い出しましたが、g07をiPhoneのデザリングに接続する際は繋がりにくかったです。
iPhoneのデザリングON/OFFやg07のWi-FiのON/OFFが必要でした。
但し、相手がモバイルルータの場合は問題はありませんでした。

なので、相性があるのだろうと思ってました。
アップデート後は変化があるのでしょうか?

2017/7/2 17:38  [2048-27]   



がんばれg07

タグ:
2/7時点 3/23時点

まず、確認出来ている事実のみ書きます。

某掲示板等で大騒ぎしているやつですが、確かに妙なアドレスへの通信要求は確認出来ます。
但し、ファームアップデート後からではなく、多分最初からです。

Network Connectionsというアプリでg07購入直後の2/7に確認しています。(2/7時点の画像)
ただ、何が通信したのかはその画像には記録されていません。
3/23はSystemUIが通信したとの記録になっています。(3/23時点の画像)


次に、SystemUI.apkがトロイの木馬であるとの情報に関して…

同ファイル内には実行ファイル本体(classes.dex)は含まれていません。
本体はodex化されてSystemUI.odexとして別ファイルで存在します。
なので、もしSystemUI.apkをファイル単体で確認したなら意味がありません。

deodex化して内容確認しようと思いましたが、今のところ成功していません。

2017/3/28 12:11  [2048-22]   

SystemUI.odexのdeodex化が出来ました。

確認していた文献がAndroid4.4以前のものだったらしく、やり方が変わっていたようです。

でも、deodex化されたSystemUI.dexが生成されると、PCのESETが即座に削除してしまいます。

削除ログによると下記の判定です。
 Android/Triada.CNの亜種 トロイの木馬
 
以下は、一時的にESETを停止させて確認しました。

生成されたSystemUI.dexをjarに変換し、実態はzipなので展開すると、下記の通りでした。

フォルダはandroidとcomの2個

android配下はサブフォルダは一つ
\android\support\v7\widgetのみで9個のファイル
 RecyclerView$LayoutManager.class
 RecyclerView$SavedState$1.class
 RecyclerView$SavedState.class
 StaggeredGridLayoutManager$LazySpanLooku
p$FullSpanItem$1.class
 StaggeredGridLayoutManager$LazySpanLooku
p$FullSpanItem.class
 StaggeredGridLayoutManager$SavedState$1.
class
 StaggeredGridLayoutManager$SavedState.cl
ass
 LinearLayoutManager$SavedState$1.class
 LinearLayoutManager$SavedState.class

com配下は全部で2009個のファイルと80個のフォルダが存在
直下は5個のサブフォルダ
 \flurry
 \mediatek
 \android
 \cool
 \facebook

どうやらTwitterで騒いでる人の指摘は正しいらしい

これからどうなるのかな…(>_<)

2017/3/29 12:36  [2048-23]   

試しに、生成されたSystemUI.dexをclasses.dexに変更してSystemUI.apkに結合してみた。

当然、ESETを有効にすると、SystemUI.dex(classes.dex)は削除されました。
しかし、SystemUI.apkは削除されず、トロイの木馬扱いされてません。

coviaの公式見解である誤検知というのは正しいのか…?

そして、facebookとか意味不明なフォルダもバグ(他PJのゴミ?)ってのも、その通りなのか…
次のファームで消えていたら確認出来るはず。


2017/3/29 12:53  [2048-24]   

忘れそうなので、SystemUIのソースを確認した手順を書いておきます。

0.準備
 必要なツール等(詳細略、adbコマンドが使える環境があること)
  oat2dex
  dex2jar
  jad

以下は、ツールがあるフォルダでコマンドプロンプトから実行

1.本体からデータを転送
 systemフォルダ配下にあるので、全体を取得
  adb pull /system
 
 実行したフォルダにsystemフォルダが作成されます。
 ※3/26版では容量2.13GBで2,533ファイルでした。
 
 SystemUI.apkは下記にあります。
  /system/priv-app/SystemUI
 実行ファイルは別でSystemUI.odexですが、下記にあります。
  /system/priv-app/SystemUI/oat/arm64

 ※上記のSystemUI.apk単体でウィルスチェック等しても意味は無いです。
  
 以下は、上記フォルダを指定しても良いのですが、面倒なのでSystemUI.odexは最初のフォルダに取り出します。
 
2.SystemUI.odexのdeodex化
 最初にboot.otaをdexに展開します。
  java -jar -Xmx1024m oat2dex.jar boot sys
tem/framework/arm64/boot.oat
 
 ※パラメータ「-Xmx1024m」はデフォルトではヒープ領域(メモリ)が不足するので宣言
 
 次に、SystemUI.odexをdeodex化します。(注)
  java -jar -Xmx1024m oat2dex.jar SystemUI
.odex system/framework/arm64/dex
  
 実行したフォルダにSystemUI.dexが作成されるはずです。
 注:SystemUI.dexはウィルス判定される場合があるので、事前にウィルススキャンを一次停止しておく。
  
3.SystemUI.dexをjarへ変換
 用意したdex2jarフォルダ内のバッチファイルを指定して実行(下記は2.0の場合)
  dex2jar-2.0\d2j-dex2jar.bat SystemUI.dex

 
 実行したフォルダ内にSystemUI-dex2jar.jarが作成されるはずです。
 
4.SystemUI-dex2jar.jarをzip展開
 SystemUI-dex2jar.jarの実態はzipなので展開ツールで展開します。
 フォルダ内で実行した場合は通常はファイル名と同じフォルダが作成されるはずです。
 
 SystemUI-dex2jarというフォルダが作成され、2個前に書いた様なファイル(.class)が確認出来ます。
 (3/20版のファームの場合)

 3/26版のファームの場合は内容が変化していました。(当然ですね…)

5.classファイルを逆コンパイルしソースを確認
 jadやJavaDecompiler等を利用して確認
 
 jadの場合はフォルダを指定して一括してjavaに変換
  jad -s java -d src -r SystemUI-dex2jar\*
*\*.class
  
 ※変換に失敗するファイルが多数あるので、JavaDecompilerの方が良いかも

2017/3/30 17:31  [2048-25]   

3/26版のファームではSystemUIを展開するとcomフォルダのみでした。
ファイル数は1,417でフォルダ数は55でした。

また、comの直下は下記の通りでした。
 \android
 \mediatek

3/20版に存在していた3フォルダが無くなりました。
 \facebook
 \flurry
 \cool

実害は無いですが、comと並列で存在していたAndroid7を連想させるフォルダは何だったのでしょう…

2017/3/30 17:44  [2048-26]   


この掲示板は閲覧専用です(運営者のみが投稿できます)。
運営者のみ投稿可
がんばれg07
がんばれg07をお気に入り登録
運営者:
亜都夢さん
設立日:
2017年3月2日
  • 注目度:

    217(お気に入り登録数:2件)

タグの登録はありません

該当掲示板はありません

縁側モバイル

携帯からも「縁側」の閲覧と投稿を行うことができます。
以下URLまたはバーコードよりご利用下さいませ。 http://m.kakaku.com/engawa/ 縁側モバイルQRコード

ページの先頭へ