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

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

紹介文

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

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

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

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

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

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

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

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

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


がんばれ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]   



がんばれ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

タグ:

昨夜のアップデートを行いました。
気がついた点のみ記載します。

1.BatteryStatsについて
 初期化されました。
 当然、設定の電池グラフも初期化されましたが、フル充電状態ではありません。

 以前はファームをアップしても初期化されずに継続して記録されていたと思います。
 初期化条件はフル充電と判定される事(電圧と温度の複合条件)のはずです。
 但し、電池温度や充電状態によって必ずしもフルでない時も誤判定?されていました。

 今回のアップデートによって初期値(本来はフル充電状態)がアップデート時の状態に変更された様です。
 従って、少しでもUSB接続等を行うと初期化されてしまいます。

 解消するには、以前と同様に、一度フル充電後に再起動させるしか無さそうです。

2.logcatについて
 直後の確認では今まで見られなかったタグが多数エラーとなっていました。
 アップデートに伴うものの可能性もあるので、念のため強制的にクリアして再取得しました。

 結果、短時間(約2時間)ですが、エラー出力されたタグ上位は…

 main E 945行/全8,282行
  ccci_fsd(1) 638行
  WifiTrafficPoller 111行
  WifiStateMachine 52行
  HAL 51行
  WifiConfigStore 42行

 system E 33行/全18,708行
  KernelCpuSpeedReader 30行
  ConnectivityService 2行
  WindowAnimator 1行

 件数(時間割合)で見ると余り変化が無い様な…
 ただ、一番件数が多いccci_fsd(1)の原因らしきものが分かりました。

 私はFOMA音声専用SIMのみで運用していますが、SIM絡みのエラーの様です。
 機内モードに変更して確認すると完全に出力されなくなりました。
 やはり本来は許されていない利用形態だからだと思われます。

 他は名前の通りWi-Fi関連が殆どです。
 HALの状況も変化無しですが、指紋を再登録する前から出力されていたので、指紋認証に関わるログでは無さそうです。

結果として、電池残量の初期値の問題を除けば、概ね良好な感じです。
まあ、元々大きな不具合を感じていなかったので、変化は感じて無いのですが…

設定の電池グラフですが、機内モードにしておくと、残時間が著しく短くなる様です。
たぶん、計算上の電池消費量が大きいという事だと思います。
機内モードを解除すると残時間が延びました。

細かくは、もう少し長期間の確認が必要かも知れませんが、とりあえずはフル順電を行ってBatteryStatsの初期値を修正したいと思います。
 

2017/3/22 12:42  [2048-16]   

logcat mainバッファのエラーの種類が異常に増加している。

アップデート前後のEが出現するタグの数は下記の通り。
 前:49種類(全15999件、61時間)
 後:166種類(全5876件、8.5時間)

あまりにも増加しすぎていて、詳細の比較をする気にもなれない…
アップデート後の値は一旦ログを全クリアした後の記録なので平常時のはず。

増えたタグの中で一番件数が多いのが、VDO_LOGでmediatekの描画系に関連しているっぽい。
他にもMtkOmxVencとかMtkOmxVdecExとか、やはりmediatekの描画系のタグが出ている。

他ユーザの評価は概ね良好みたいだけど、ログの状態は悪化しているようにも見える。
このまま放置して状況の変化を確認してみます。

2017/3/23 00:06  [2048-17]   

長時間放置するとエラーの割合が減るようです。

前回の状態のまま時間のみ経過したところでログ採取しました。

前回 :166種類(全5,876件、8.5時間)

今回1:133種類(全11,030件、21時間)
    ログエリアがMAXになったらしく、前回より記録開始時刻が30秒遅れになっている。
    従って、30秒間で33種類のエラーが出力されていた事になる。

今回2: 68種類(全11,861件、25.5時間)
    今回1から5時間後の状態で、記録開始時刻は30分遅れ
    アップデート前のエラーの種類に近くなってきました。

推測ですが、フル充電後に再起動した事によって、一時的に動作するタスクが増えて、それに伴いエラー種類も増えただけなのかも知れません。
アップデート前と同様に安定した状態になると、エラー種類はそれ程変化していないという結果になるかも知れません。

更にある程度放置した後でlogcat採取し、アップデート前と比較してみます。

2017/3/24 00:49  [2048-18]   

前回から更に経過後のmainバッファに記録されたエラーの状態

71種類(全13,657件、24時間)

採取時刻は前回の20時間後ですが、記録開始時刻は22時間後となっています。
昨日はスリープ状態では無く、ナビ通信等で使用していた為に、ログの量もそれに伴ってエラー自体も増加したと考えられます。

件数上位のタグとE件数は下記の通りでした。

 HAL        4,406
 WifiTrafficPoller 3,354
 ccci_fsd(1)    2,378
 WifiConfigStore   955
 WifiStateMachine  659
 MPlugin       321
 FingerCD       274
 WifiMonitor     172
 Surface       133
 NativeCrypto     118

重複もありますが…Wi-Fi関連以外は…
 HAL
  指紋関連でsucessになっている

 ccci_fsd(1)
  SIM関連でFOMAのみでの運用が原因と思われる
  Wi-Fiエリア内で利用しているとWi-Fi関連が増加して、相対的に減少してくる

 MPlugin
  mediatekのプラグインって事でしょうか?
  出力されているメッセージと件数は下記の通りです。
 Unsupported class: com.mediatek.systemui
.ext.ISystemUIStatusBarExt 154
   Unsupported class: com.mediatek.common.t
elephony.IOnlyOwnerSimSupport 151
   Unsupported class: com.mediatek.settings
.ext.ISettingsMiscExt 11
   Unsupported class: com.mediatek.settings
lib.ext.IWifiLibExt 1
   Unsupported class: com.mediatek.systemui
.ext.INavigationBarPlugin 1
   Unsupported class: com.mediatek.browser.
ext.IBrowserSettingExt 1
   Unsupported class: com.mediatek.browser.
ext.IBrowserRegionalPhoneExt 1
   Unsupported class: com.mediatek.settings
.ext.IAppsExt 1

 FingerCD
  指紋関連でしょうか?
  アップデート後に増えてますが、指紋登録をかなり適当に行ったので、それが理由かも

 Surface
  Android6.0固有の既知問題らしい
  エラー時のメッセージは全て下記形式(y部分がアドレス)
   getSlotFromBufferLocked: unknown buffer:
0xyyyyyyyyyy

 NativeCrypto
  メッセージから判断してSSL関連のエラー?
  メッセージは下記の様な(アドレスは変化)感じ
   ssl=0xyyyyyyyyyy cert_verify_callback ca
lling verifyCertificateChain authMethod=
ECDHE_RSA
   ssl=0xyyyyyyyyyy cert_verify_callback ca
lling verifyCertificateChain authMethod=
ECDHE_ECDSA
   ssl=0xyyyyyyyyyy cert_verify_callback x5
09_store_ctx=0xyyyyyyyyyy arg=0x0

Wi-Fi関連は…
 WifiTrafficPoller
  メッセージを分類してみると以下の通りですが、何故Eなのか理解不能

   TRAFFIC_STATS_POLL true Token 277 num cl
ients 7
    1372件、トークン番号は変化、num以降は無い場合もあり最後の数値も変化
   packet count Tx=xxxxxx Rx=yyyyyy
    1366件、パケット数のカウント、xxxxxxとyyyyyy変化(増加)
   notifying of data activity 3
    436件、最後の数値は変化
   ENABLE_TRAFFIC_STATS_POLL false Token 25
7
171件、トークン番号は変化、ポーリング結果が否って事か?
   ADD_CLIENT: 9
    9件、数値は変化、ポーリングした結果で発見したクライアントを追加って事?
    
 WifiConfigStore
  接続したアクセスポイントの情報を格納しているっぽい
  ただ、明確にエラーと読めるメッセージが判別出来ない
  下記の様なメッセージが多い
   saveWifiConfigBSSID Setting BSSID for &q
uot;SSID名"WPA_PSK to any
   updateConfiguration freq=5180BSSID=MACアドレス RSSI=-44 "SSID名"WPA_PSK

 WifiStateMachine
  下記ソース内のコメントを説明を直訳によると、「Wi-Fi接続状態の追跡機能」って事?
   https://android.googlesource.com/platfor
m/frameworks/opt/net/wifi/+/android-6.0.
0_r1/service/java/com/android/server/wif
i/WifiStateMachine.java

 WifiMonitor
  これも…「WPA接続要求サーバ?からのイベントをWifiStateMachineに渡す」って事?
   https://android.googlesource.com/platfor
m/frameworks/opt/net/wifi/+/android-6.0.
0_r1/service/java/com/android/server/wif
i/WifiStateMachine.java

  エラーの殆ど(132件)が下記だけど、知らないイベントだからエラーって事??
   handleEvent unknown: 14 CTRL-EVENT-SCAN-
STARTED
   
電池履歴詳細のグラフでWi-Fiが消えない理由が上記の何処かにあると思うけど、まだ特定出来ていない。

縁側の掲示板って…
英文(URL等)が勝手に改行されるのと、顔アイコンが固定されないのは面倒だ(>_<)

2017/3/25 11:18  [2048-19]   

ファームアップ直後取得 昨日昼取得 今朝取得

一度フル充電して再起動後からは、Wi-Fi接続で情報取得していました。
何故か今朝はWi-Fi経由でadbサーバに接続が出来なかったので、USB接続で取得しました。
(前レスで書いた情報は昨日取得分)

logcatしか見てなかったけど、電池詳細グラフ確認したら、初期化されている事が判明。
USB接続による充電でグラフ(BatteryStats)の初期化判定がされてしまったらしい。

ファームアップ時の電池残量が初期値として記録されたままになっている感じ…
実使用上は問題無さそうだけど、微妙に気持ち悪い。
(グラフ命の某氏だったら大騒ぎしそうw)

端末初期化すれば解消するとは思うけど、面倒くさい…(>_<)

2017/3/25 12:00  [2048-20]   

本当に前回はフル充電出来ていたのか自信がなくなってきたので、再度フル充電を行って確認中。

電池詳細グラフの残量表示が今までと違っている気がします。
まあ、グラフなんて目安でしかないので、それだけで変だとは言えません。

今まで
 100%から99%になるまでは、かなりの時間を要していた。

今回
 6時間で100%から98%になった
  最初が100%でなければ正常な減少率です。
 17時間で100%から96%になった
  最初に比べて減少率が大幅に下がっています。
 
原因
 BatteryStatsの電圧と温度の記録を確認したところ、温度に大きな変動がありました。
  経過時間 記録
  00:00:00 temp=230 volt=4263
  00:00:49 temp=240 volt=8526
  00:36:39 temp=230
  00:41:19 volt=8484
  01:50:13 temp=220
  01:52:33 temp=210
  04:15:39 temp=200
  04:17:59 temp=190
  05:45:01 temp=180 volt=8485
  06:18:46 temp=190 volt=8484
  06:22:24 volt=843
  06:23:34 temp=200 volt=8430
  06:39:47 temp=210 volt=8382
  08:45:15 temp=220 volt=8383
  08:47:35 temp=210 volt=8436
  14:15:24 temp=200
  14:16:34 temp=180
  14:17:44 temp=170
  14:18:54 temp=160
  14:20:04 temp=150
  15:45:18 volt=8437

 やはり、電池温度が下がると計算上の電池残量は結構減少するようです。
 温度は0.1度表示のようです。
 それにしても、voltの数値の意味がよく分かりません。
 最初だけ値が大幅に違ってます。
 単位が不明ですが、mvだとすると、最初以外の8Vは高すぎる気もします。

2017/3/26 12:26  [2048-21]   



がんばれg07

タグ:
電池履歴

dumpsysで取得可能なBatteryStatsですが、これが電池グラフの元になっていると思われます。

logcatのエラーをカウントした時に取得したBatteryStatsを確認してみました。
記録は20,435行で3日と17時間48分ありました。
BatteryStatsの記録は開始時刻からの経過時間なので、EXCEL上で記録時刻を計算してます。

グラフは同時刻のものです。
USB接続をしていないの若干見にくいですが…

取得内容を見ると、基本的には何かが動作する時は+で終了時に-で表示されているようです。

例えばGPSに関して確認すると…
 全部で38行あって、半分が+、半分が-で交互になってます。
 これは、開始したものが正常に終了しているって事だと思います。
 開始と終了の間は、殆どが10秒程度から30秒未満ですが、一部2分台と3分台があり、それがグラフ上に現れています。
 
Wi-Fiグラフがほぼ常時表示されているのですが、設定上はスリープ時は接続しない様にしてあり、実際も接続出来ません。
従って、グラフ表示が間違っていると判断していますが、確認してみると…
 wifiが含まれるのは全部で2,457行あり、+-にはほぼ下記のいずれかでした。
  wifi、wifi_running、wifi_full_lock、wifi_scan、wifi_radio

 ただ、GPSと異なり単純にwifiだけでは無い上に、1行に複数のwifi関連が出力されているので、単純に+と-が対にはなっていないようです。
 
 もしかしたら、それが原因でグラフが途切れないのかも知れません。
 唯一、グラフが途切れている部分(15日の終わりくらい)のみ+と-が交互に出現しています。
 
 これも推測ですが、+の対で-が無くても、時々出現する-wifi_full_lockでWi-Fiは切断されるけど、グラフ上は対の-が出ないと描画を止めないって事かも。
  
 一部では理由としてモジュール名が記録されていて、Androidそのもの以外に、インストールしたアプリやmediatek関連と思われるモジュールあります。
 やはりここでもmediatek特有の原因が存在するのかも知れません。
 
 今週のファームアップで状況が変化するかどうか楽しみです。
 

2017/3/20 14:26  [2048-15]   



がんばれg07

タグ:

logcatで出力可能なログについて

いつもdeveloper.android.comで調べるのですが、日本語ページが正確では無い事に気付きました。(今更?)

例えば、logcatについては下記に記述がありますが、画面下部で表示を英語に切替えると全く情報が違います。
https://developer.android.com/studio/com
mand-line/logcat.html


日本語ではデフォルトのログバッファはmainのみになっていますが、英文ではmainに加えてsystemとcrashもデフォルトになっています。
実際も3バッファが出力されているので、英文が正しいです。

他の利用可能なオプションの数も日本語ではかなり少ない表示になっています。
英文が必ず正しいのかは不明ですが、少なくとも日本語よりは良さそうです。


で、logcatの-bオプションで指定可能は下記です。未指定の場合はdefault分が出力されます。

radio
 View the buffer that contains radio/tele
phony related messages.
events
 View the interpreted binary system event
buffer messages.
main
 View the main log buffer (default) does
not contain system and crash log message
s.
system
 View the system log buffer (default).
crash
 View the crash log buffer (default).
all
 View all buffers.

何かを調べる時に、ある程度範囲が限定出来たら、対象バッファも限定して確認した方が良さそうです。
Wi-Fiや電話が少し不安定な感じもするので、radioも明示的に確認した方が良いのかも。

2017/3/12 12:05  [2048-7]   

ログバッファのサイズを最大にしても、通常利用中なら、1日は無理っぽいです。
人間だったら安静にした状態で1日って感じかも。

記録時間は別にして、-dのみ指定した場合は何度取得しても容量が約44MBになります。
g07で設定した16MBというのはバイナリでテキスト化された時に、このサイズって事なのか…。

-bオプションでall指定した場合は、70MB弱にもなりました。
EXCELで読込んで空白行等を削除した後で、各バッファの出力数などは下記の通りでした。
 main 10万行、25分間
 system 30万行、12時間
 radio 19万行、21時間
 events 2万行、76時間

当然、ログ取得のタイミングで各出力数は結構変動します。
でも、確実に言えるのは、調べたいタイミング(時刻)を限定しないと原因を見つけるのはかなり困難って事です。

2017/3/12 12:24  [2048-8]   

公開中止になったファーム「Ver:CP-J55a_20170306」にしたら、logcatの様子が変わりました。
とりあえず、デフォルト状態でしか確認してませんが…、
mainバッファには殆ど(5時間で3行のみ)出力されなくなりました。

確かに、今までは同じタグが両方にあって変だとは思っていたのですが…

今回のファームでの改善点は、下記でした。
 スリープ時に指紋センサーが浪費することがある微量なバッテリー消費を抑制

これで、スリープしない様に見えていた個体は改善されたのでしょうか?
自分のはスリープは問題無さそうだったので、アップデート後も変化は感じません。

ログ上は指紋関連と思われるエラーは下記で、アップデートに関わらず多数出力されています。
 HAL : aaaopen fingerprint halllib sucess

重要度がEなのでエラーだと思うのですが、何故かsucess?

前に書いたallで取得した時は、mainで618回(25分間)、systemで1827回(12時間)でしたが、
アップデート後は、systemのみで1247回(5時間)です。

以前はmainに出力されていた分がsystemに纏まったと考えれば妥当な(減少した)のかな…

2017/3/15 00:22  [2048-11]   

さらに放置した状態で再確認したら、以前と余り変わっていない感じ。

mainで980回(2時間弱)、systemで1605回(16時間)

記録時刻がmainが2時間弱に続いてsystemになっているのは何故だろう?
過去のログもそうなってる…
ログバッファが違う=記録されるログの種類が違うでは無いのか?

念のため、明示的にバッファを指定してログ取得すると同じ時刻の記録が存在するっぽい。
デフォルト出力の仕様なのか?バグなのか?

しかも、結果が…不思議

mainで2567回(16時間、全197502行)、systemで0回(12.5時間、全153092行)

これは…adbコマンドにバグがあるのかadbに対するg07の反応が変なのか、どっちだ?

ログは信用出来る(と言うより信用しないと何も出来ない)と思っていたけど、そうでも無い感じ。

これは、g07の問題なのか?それともAndroid共通の問題なのか?
後者なら、騒ぐ人が居るはずだから、前者なのか???

自分の個体には今のところ大きな問題は無さそうだけど、何を信用して良いか分からない状態は困る…

2017/3/15 13:23  [2048-12]   

logcat取得時には-bを付加してバッファを指定する事にしました。

今日取得した状況(2,3日は完全に放置状態でした)
取得はUSB接続をせずにWi-Fiで行っています。

main 234,204行、61時間
 E 15,229行
 W 42,995行

system 156,395行、23.5時間
 E 373行
 W 2,464行

radio 258,449行、65時間
 E 3,707行
 W 816行

数だけの問題では無いと思いますが、mainバッファにエラーが多数出力されている事が分かります。

各バッファのEが出力されているタグ上位は以下の通りです。

main
 ccci_fsd(1) 4,571行
 ctxmgr 2,761行(Wも1,422行)
 HAL 2,028行
 Sensors 1,620行
 WifiTrafficPoller 1,330行

system
 KernelCpuSpeedReader 354行

redio
 RILC 3,414行
 RIL 176行

それぞれのタグが意味するものは何か?

単にググってヒットしただけなので、正確かどうかは?ですが…、

main
 ccci_fsd(1)
  mediatek関連のドライバの様です。
  https://android.googlesource.com/kernel/
mediatek/+/android-6.0.0_r0.6/drivers/mi
sc/mediatek/dual_ccci/include/ccci_fs.h


 ctxmgr
  ContextManagerだと思います。
  下記の情報を単純翻訳すると、Contextは「アプリケーション環境に関するグローバル情報へのインターフェース。」…
  要するに、アプリ全体の管理(どこから起動され、どこにアクセスしようとしているか等)をしてるって事??
  https://developer.android.com/reference/
android/content/Context.html?hl=ja

  
 HAL
  たぶん、Hardware Abstraction Layerの意味だと思います。
  ドライバやctxmgrとの違いが今ひとつ分からないけど…
  ただ、前にも書いた様に、全てが下記なので指紋のエラー?です。
   aaaopen fingerprint halllib sucess

 Sensors
  文字通りセンサー関係だと思いますが、一番多い(1,056行)メッセージは下記です。
   handleToDriver handle(0)
  
 WifiTrafficPoller
  Wi-Fiのトラフィックの統計情報をポーリングし、クライアントに通知する機能らしいです。
  http://tools.oesf.biz/android-6.0.0_r1.0
/xref/frameworks/opt/net/wifi/service/ja
va/com/android/server/wifi/WifiTrafficPo
ller.java


 KernelCpuSpeedReader
  CPU速度のリーダー?、異なる速度のCPUを制御?する仕組みの一部でしょうか?
  http://tools.oesf.biz/android-6.0.0_r1.0
/xref/frameworks/base/core/java/com/andr
oid/internal/os/KernelCpuSpeedReader.jav
a


 RILC
 RIL
  Radio Interface Layer…ハードと電話サービス間のレイヤーって事?
  http://tools.oesf.biz/android-6.0.0_r1.0
/xref/hardware/ril/libril/ril.cpp

  
数の多いエラーから類推すると、
 mediatek製SoCで、アプリとハードとのインターフェースに問題があって、指紋センサーやWi-Fi、電話等に障害が出る可能性がある
 速度の異なるCPUの制御にも問題がある
って感じでしょうか?(かなり適当ですけど)

何となく現実で報告されている障害に近い感じもしなくも無いですね…
  
  
最後に蛇足…logcatのソースはこれっぽい…
http://tools.oesf.biz/android-6.0.0_r1.0
/xref/system/core/logcat/

2017/3/18 17:26  [2048-13]   

公式Twitterでアナウンス出ましたね…
やはり、logcatのエラーから推測されたとおりって事なのかな。

来週のアップデートを待って、logcatの変化を確認してみたいと思います。

2017/3/19 10:54  [2048-14]   


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

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

タグの登録はありません

該当掲示板はありません

スマートフォン・携帯電話 > スマートフォン > コヴィア・ネットワークス >

g07 SIMフリー [ホワイト]

g07 SIMフリー [ホワイト]

価格登録なし

2134件53.81

縁側モバイル

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

ページの先頭へ