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

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

紹介文

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

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

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

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

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

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

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

がんばれ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
がんばれg07をお気に入り登録
運営者:
亜都夢さん
設立日:
2017年3月2日
  • 注目度:

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

タグの登録はありません

該当掲示板はありません

縁側モバイル

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

ページの先頭へ