縁側 > スマートフォン・携帯電話 > すべての書き込み
「縁側」-みんなが作る掲示板-からのお知らせ
縁側からのお知らせ

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

  • スマートフォン・携帯電話の掲示板

「スマートフォン・携帯電話」

所属カテゴリにして 掲示板を作成する

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

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


返信2

お気に入りに追加

運営者のみ投稿可


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



返信5

お気に入りに追加

運営者のみ投稿可


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



返信0

お気に入りに追加

運営者のみ投稿可


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



返信5

お気に入りに追加

運営者のみ投稿可


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



返信5

お気に入りに追加

運営者のみ投稿可


がんばれg07

タグ:

何故、ログを見る必要があるか?
それは、スマホで表示される情報だけでは何も分からないからです。

グラフ等に違いがあっても原因は全く分かりません。
条件を変えて、一つ一つ切り分ければ判明する可能性もありますが、スマホの状態が前回と同じである保証も無いです。

なので、最初からログを確認した方が近道です。

ログはadbコマンドで取得出来ます。

adbが使える状態にするには、Android SDKかそれが含まれるAndroid Studioが使える環境を作る事です。
方法はググれば沢山出てくるので割愛します。

adbコマンドは基本的にPCのコマンドプロンプトから利用します。
形式はadb xxxxx で、更にオプション(引数等)が使えるコマンドもあります。


ログの種類は確認出来た範囲で大きく2つ(他にもあるかも)
 
1.logcat
 基本的なコマンド : adb logcat

 但し、このままでは終わりが無く、たぶん無限に出力され続けます。
 コマンドプロンプトウインドウの表示量には限度があるので、
 出力結果はファイルにリダイレクト(出力先を変更する事)すべきです。

 logcatにはいくつかのオプションがありまので、必要な場合は追加します。
 https://developer.android.com/studio/com
mand-line/logcat.html?hl=ja


 adb logcat -d とすれば、コマンド発行時点でのログ全体を出力して終了します。 

 出力内容としては、時系列で動作状況が記録されています。
 日時(1/1000秒まで)、PID(プロセスID)、TID(スレッドID)、優先度、タグ、メッセージ

 優先度がより深刻で、特定のタグやテキストが頻繁に出力されている場合は要注意です。

 優先度とは、AndroidStuadioのドキュメントを見ると下記らしいです。
 今のところE迄しか見た事はありません。
  V - Verbose(最も低い優先度)
  D - Debug
  I - Info
  W - Warning
  E - Error
  F - Fatal
  S - Silent(最も高い優先度。何も出力されません)

 タグとは、そのメッセージが出力されたシステムコンポーネントの略称

 但し、ターゲットにする時刻やタグ等を決めて調べないと、難しいと思います。
 AndroidStudioに含まれるDeviceManagerを使えば多少は楽になりますが、使い勝手は…

 私は使い慣れているEXCELに読み込んでフィルタや検索しています。
 ログ自体はテクストファイルなので、EXCELに読み込む場合は工夫が必要です。

 もう一つのログや、EXCELへ取り込む方は別途、書きます。

2017/3/3 00:48  [2048-2]   

今日も続きを書こうと思っていましたが、表?での出来事でやる気無くしてます。

お気に入りにして頂いた方もいらっしゃるようですが、申し訳ありませんが少し冷却期間をおかせて頂きます。m(_ _)m

今更ですが、顔アイコンは共通(表の設定が引き継がれる)では無かったのですね…

2017/3/3 21:55  [2048-3]   

数日放置してますが、何故か注目ランキングが上がってる…?

ちゃんと整理してから書けば良いのだけれど、とりあえず備忘録として書いて整理は後回しにします。


必要なログ類を纏めて取得するコマンドがありました。

adb bugreport

複数指定するのが面倒な場合はこれ一つでも良いかも。

ただ、それが言いたいのではなく、適当に入れたAndroid Studioの環境が合ってないのかもって事に気付きました。

私の環境では、このコマンド実行時に下記メッセージを出力します。
Failed to get bugreportz version, which
is only available on devices running And
roid 7.0 or later.
Trying a plain-text bug report instead.

このメッセージの前と後に、スマホ本体が2回+α鳴動します。

たぶん、Android7.0以降との互換性が無いって事だと思います。

仕方無いので、再インストールする事にしました。
以前は、AndroidStudioをダウンロードしていたのですが、利用しないアプリでストレージを消費するのは無駄なのでSDKのみにします。

AndroidStudioをアンインストールしたら7GB位空きが増えました。(最初をよく見てなかったので不正確ですが)

2017/3/8 22:22  [2048-4]   

Android SDKのインストールについて書きます。

それ以前にjava環境が必要なので、環境が無い方は下記ページから利用環境に合ったJava SEを入手して下さい。
JDK DOWNLOADをクリックすると一覧が出るので、Java SEを合わせてダウンロードしインストールします。
http://www.oracle.com/technetwork/java/j
avase/downloads/index.html


新たにSDKをダウンロードします。
以前はSDK専用のページがあった様ですが、以前のページをアクセスしても下記へリダイレクトされます。
https://developer.android.com/studio/ind
ex.html


ページの下の方にスクロールし、「コマンドライン ツールのみ入手する」部分からダウンロードします。
私はWindows版のtools_r25.2.3-windows.zip(書いた時点)をダウンロードしました。

※実はスクロールするよりメニューのダウンロードオプションをクリックすれば、「Android Studio を使い始める」まで移動するので早いです。

以前は、インストーラ版が存在していた様ですが、今はzipしかないので、利用したいフォルダに展開します。

toolsというフォルダが作成されると思います。
もし、他の場所で展開してしまった場合は、作成されたtoolsを目的のフォルダに移動します。

toolsフォルダ内のAndroid.batを実行するとSDKマネージャーが起動し、必要なパッケージを追加削除可能です。
いくつかのチェックボックスはチェック済みになっていますが、このままインストールすると不必要なパッケージもインストールされ無駄です。

私の場合、チェックが入っているのは、下記の通りでした。
tools
 Android SDK Tools
 Android SDK Platform-tools
 Android SDK Build-tools

Android 7.1.1(API25)
 全て

Extra
 Google USB Driver
 
この中で、必要なのは、Android SDK Platform-toolsとGoogle USB Driverだけです。
他のチェックは全て外して構いません。

2つのパッケージをインストールします。
インストールが完了すると、最初にtoolsを作成したフォルダ内にplatform-toolsフォルダが出来ているはずです。
ここにadbコマンドがあります。

インストールが完了したら、Windowsの環境変数にPATHを追加します。
PATHはplatform-toolsフォルダに通します。

ちなみに、環境変数はユーザとシステムがありますが、ユーザだけで構いません。
慣れていない方はシステム側は触らない方が良いです。

もし、既存のPATHが無い場合は、新規でPATH(大文字でも小文字でも可)を作成し、フルパスで書きます。

 d:\Android\SDK\Platform-tools

既存のpathがある場合は編集で上記を追加します。
Windows10の場合は編集用のダイアログが出るので、新規で項目追加して上記を記述します。
ダイアログが出ないバージョンの場合は、既存のpathに区切り記号;を追加して、上記を加えます。

もし、環境変数って何?てレベルの人なら、無謀な挑戦のような気がするので、止めておいた方が良いと思います。
万一、PC等が起動しなくなっても責任は持てません。

また、過去に上記に関連するモジュールを利用していた(中途半端なインストールでも)場合は、正常に更新されない可能性もあります。
もし、正常に使用出来ない場合は、関連しそうな項目を探して削除するなど、リトライして下さい。

スマホ側の設定
 デバッグモードをONにする必要があります。
 デバッグモードは開発者向けオプションの中ですが、開発者向けオプションはデフォルトでは非表示です。

 開発者向けオプションを有効にするには、設定-端末情報でビルド番号部分を7回タップします。
 
 設定に開発者向けオプションが表示されたら、USBデバッグを有効にします。
 また、USB設定の選択がMTPになっている事を確認します。
 
PCとスマホの接続
 USBケーブルで接続します。
 正常に認識出来ていれば、ポッポアップで通知されます。
 しかし、このモデルでは初期状態だと正常に認識出来ないようです。
 
 その場合はデバイスマネージャーから、ポータブルでバイス内で!マークが付いているはずのCP-j55aを右クリックします。
 ドライバーソフトウェアの更新を選択します。
 コンピュータを参照して…(下側)を選択します。
 コンピュータ上のデバイスドライバーの一覧から…を選択します。
 ドライバの選択画面になるので、互換性のあるハードウェアを表示のチェックを外します。
 一覧から、製造元:(標準のMTPデバイス)、モデル:MTP USBデバイスを選択し次へで更新して下さい。
 これで、接続出来たはずです。
 
 もし、NGの場合は、これ以前で何かミスがあるか、個別の問題がある可能性があります。

adbが利用可能か確認
 PCのコマンドプロンプトからadbを入力してヘルプが出ればOKです。
 スマホと正常に接続出来ていれば、adb devicesで接続しているスマホの製造番号が出力されるはずです。
 
ここまでやりましたが私の環境でのadb bugreportのエラーは消えませんでした…(^_^;)

が、やっと分かりました。
古いPlatform-toolsを直接ダウンロードし、置換すれば良いだけでした。

最新のPlatform-toolsは下記なので、25.2.3を25.2.2に書替えてダウンロード可能でした。
https://dl.google.com/android/repository
/tools_r25.2.3-windows.zip?hl=ja


これで、adb bugreport実行時のエラーは消えましたが、端末の鳴動はそのままでした。
adbバージョンに起因するものでは無かった様です。

2017/3/8 22:27  [2048-5]   

一つ書き忘れました。

開発者オプションの中に「ログバッファのサイズ」という項目があります。
デフォルトは256Kだったと思いますが、このままだとlogcatはあっという間にリサイクルされます。

超安定稼働していたとしてもエラー以外も出力されているので、デフォルトのままでは使えません。

私は最大の16Mに変更しました。
ログの出力状況次第ですが、1日分程度はログが残る様です。

ただ、EXCELに取り込むと約345,000行にもなってました…

g07の小さな筐体からこんなに大きなファイルが…と、意味も無く少し感動w

このサイズ変更が有効なのはlogcatだけ?だと思います。
バッテリの状況を記録したBatteryStatsは256KBのままで変更されませんでした。


もう一つ、ログによって、初期化条件が異なる様です。

logcatは勝手にリサイクルされる他には、再起動で初期化される(取得サイズが小さくなる)感じです。

BatteryStatsは少し厄介です。
まず、リサイクルされませんし、単に再起動しても初期化されません。

ちなみに、BatteryStatsは設定のバッテリーグラフの元データだと思います。

そこで、グラフの初期化について若干触れておきます。
グラフが初期化されるのは、”基本的には”バッテリーがフル充電された時です。

問題なのは、この”基本的には”の部分です。
フル充電の判定は、出力電圧と温度によって行われている感じです。
通常は出力電圧は利用とともに低下していきますが、温度は色々な条件で上下します。

もし、温度が上昇すると計算上は利用可能時間は延びる事になります。
しかし、当然、グラフ上は充電していない限り利用可能時間増加(バッテリー残量増加)にはなりません。

問題はログ取得や他の理由でUSB接続で若干でも充電がされた時に、内部計算上でフル充電の判定がされてしまうと、グラフは初期化されてしまいます。
でも、バッテリー残量(数値表示)だけは、ほぼ以前のままなので、見た目上はフル充電されていないのにグラフが消える事になります。

概ね、90%以上の残量表示で発生する可能性があります。

グラフが初期化される条件の時はログも初期化されます。
なので、電池残量が多い時にUSB接続ログを取ろうとするのは、若干リスクがあるって事です。

更に、フル充電判定にならない様に運用した場合、256KBのサイズを越えると当然ながらログが正常に取得出来ません。
全く出来ない訳では無く、少しだけ残ったりします。 ※

この時に、フル充電を行うとグラフは一見正常に初期化された様に見えますが、ログを確認すると※の時と同じ状態で殆ど記録されていません。
この状態になるとグラフも更新されなくなります。

たぶん、ログ記録位置のポインタが初期化されていないのだと思います。
これは再起動で解消されます。

グラフ等の表示が変だと思った時は、とりあえずフル充電後に再起動を行えば正常に戻る可能性があると言う事です。

原因を調査等する場合は、ログ取得後ですが…

2017/3/8 23:32  [2048-6]   

亜都夢 さん  

2017/3/12 13:15  [2048-9]  削除

スマホと正常に接続出来る前提でログ等を取得するバッチファイル例です。

BatteryStatsの3オプションを取得後にlogcatを取得して、最後に電池履歴画面のスクリーンショットを撮っています。

ログ及びスクリーンショットの保存場所は環境に合わせて書換が必要です。
スクリーンショットの1次保存場所はSDカードにしてますが、手動のスクリーショットの保存場所をコメントで載せてます。

また、xxxxxxとなっている部分はロック解除の為のPINに書換が必要です。
自動でロック解除をしない場合は該当箇所を削除した上で、手動でロック解除後に実行します。

この掲示板の仕様なのかも知れませんが、一部で途中で改行されてしまいます。
下記では、何カ所か改行されてしまいます。
元はadbをはじめ、set、rem等バッチファイルで使用可能なコマンドで始まる部分が1行です。

以下、バッチファイル例 --------------------------------------

@echo off

rem デバイス接続待ち
adb wait-for-device

rem 充電状態を解除(ログ取得中のクリアを防ぐ為)
adb shell dumpsys battery unplug

rem 環境変数はバッチファイル内のみ有効とする
setlocal

rem ファイル保存先等の設定(環境によって変更)-----------------------

rem 日付取得
set dt=%date%

rem 時刻取得、空白を0に置換
set tm=%time: =0%

rem ファイル名生成(形式は日付_時刻)
set f2=%dt:~-10,4%%dt:~-5,2%%dt:~-2,2%_%
tm:~0,2%%tm:~3,2%%tm:~6,2%

rem ログ保存先
set dl=d:\work\log\

rem スクリーンショット保存先
set ds=d:\work\Screenshots\

rem ログ拡張子
set ex=txt

rem ログ出力対象一覧(adb shellで取得出来るもの、必要に応じ追加削除)
set tg[1]=wifi
set tg[2]=batterystats
set tg[3]=alarm

rem 本体のスクリーンショット保存場所(SDカード)
set sc=/sdcard/

rem 本体のスクリーンショット保存場所(標準機能の保存場所)
rem set sc=/storage/sdcard0/Pictures/Scr
eenshots/

rem スクリーンショット一次ファイル名(上記保存場所に記録)
set sn=screen.png

rem 設定終わり -------------------------------

rem ログの取得 ----------------------------

rem 対象数分の繰り返し処理
set i=1
rem 以下を条件不成立になるまで繰返し
:start

rem f1にtg[i]の値を代入
call set f1=%%tg[%i%]%%

rem f1が定義されている(出力対象一覧に記述がある)場合に実行
rem iを1ずつ加算しながら繰り返し
if defined f1 (
echo %f1% 作成中
adb shell dumpsys %f1% > %dl%%f1%_%f2
%.%ex%
set /a i+=1
goto :start
)

rem おまけでlogcat取得 ------------

echo logcat 作成中
adb logcat -d > %dl%logcat_%f2%.%ex%

rem おまけ終了 ---------------

rem 充電可能に戻す
adb shell dumpsys battery reset

rem 電池のスクリーンショットの取得 ---------------------------

rem スリープ解除
adb shell input keyevent KEYCODE_MENU

rem PIN入力
adb shell input text xxxxxx
adb shell input keyevent ENTER

rem 設定画面の表示
adb shell am start -a android.intent.act
ion.MAIN -n com.android.settings/.Settin
gs > nul
adb shell am start -n com.android.settin
gs/.Settings > nul

rem スワイプ
adb shell input swipe 540 1500 540 500

rem 電池を選択
adb shell input touchscreen tap 540 1450



rem 1秒待ち(念のため)
timeout /t 1 > nul

rem スクリーンショット取得
adb shell screencap -p %sc%%sn%adb pull
%sc%%sn% %ds%battery_%f2%.png > nul
adb shell rm %sc%%sn%

rem 電池履歴の表示
adb shell input touchscreen tap 540 800

rem 1秒待ち(念のため)
timeout /t 1 > nul

rem スクリーンショット取得
adb shell screencap -p %sc%%sn%
adb pull %sc%%sn% %ds%battery_history_%f
2%.png > nul
adb shell rm %sc%%sn%

rem スクリーンショット終わり --------------------------------

rem 設定画面の終了
adb shell am force-stop com.android.sett
ings

rem アプリ一覧表示(設定以外が無い前提)
adb shell input touchscreen tap 838 1860



rem 1秒待ち(念のため)
timeout /t 1 > nul

rem アプリ一覧から設定を削除
adb shell input touchscreen tap 925 395

endlocal

2017/3/12 13:20  [2048-10]   



返信0

お気に入りに追加

運営者のみ投稿可


がんばれg07

タグ:

個人的にスペック面について思うところなど、羅列してみます。

メモリーやストレージ、カメラ画素数、バッテリー容量などは4万円程度する他機種と同等か若干劣る程度になっています。

通信バンドは最低限をカバーしている感じで、場所によっては(東名阪での高速通信や一部地方都市には非対応)不便があるかもしれません。

色々問題が発生している様ですがFOMAカード正式対応とアナウンスしているのも良いところです。

SDカードについてはSIM2と排他なので、内蔵ストレージで足りない様な人には致命的なのかも。

衛星測位方式はGPS(米国)とGLONASS(ロシア)のみの対応で、最近増えているBDSS(中国)や2018年に4基体制になる予定のQZSS(日本)には非対応です。
価格の高い中国製機種ではBDSS対応が多いですが、QZSS対応はまだ少ないので仕方無いところですが。

Wi-Fiは802.11a/b/g/n対応でこの価格で5GHz対応は立派だと思います。
4万円クラスになるとacにも対応しているのですが、それを望むのは無茶ですね。

Bluetoothについても基本的に使いそうなプロファイルには対応しています。
もっともアプリで追加出来たりもするので、そんなに重要じゃないかもしれません。

センサ類も上位モデルと比較しても遜色無いです。

最近のモデルでは当たり前になりつつありますが、USBがType-Cなのは良いところだと思います。
スペアでケーブル購入すると若干高く付きますけど…

最後にCPUですが、MediaTek製のMT6750Tで1.5GHzのA53が4コアと1.0GHZのA53が4コアのbig.LITTLE構成になっています。

完全に推測ですが、問題が発生しているらしいRaijinでも同じCPUだし、同じメーカの6755Mでも問題があるらしいので、big.LITTLEに何か問題があるのでは...なんて思っています。

その思いを強くしたのは…最近人気トップのnovaは今まで使用していたHiSilicon(元Huaweiの一部門)のKirin(最近のはbig.LITTLE)を使わずに、Qualcomm製のSnapdragon625(big.LITTLEでは無い)を採用してるのですよね…

2017/3/2 15:25  [2048-1]   


「スマートフォン・携帯電話」

所属カテゴリにして 掲示板を作成する

ページの先頭へ