NEW_OUTGOING_CALL

OCN電話のプレフィックスを付加させる動作で手元のスマホで動作が少しおかしいので少し調べてみました。

ダイアルするときに

「発信できません。」

というダイアログが表示されるもののしっかりと付加処理後の番号でダイアルされている感じに。

通話なんて滅多に使っていませんでしたが、そういえばずいぶん前にファームのアップデートがありました。

ターゲットとなる端末の状態は…
ビルド番号 01.00.05
Android 5.0.2
カーネルバージョン 3.4.0
古い端末になりますが、買い換えようと思いつつも、SH-M02使い続けています。

動作を調べてみたところ、1回のダイヤルで2回NEW_OUTGOING_CALLを受信している感じなので、ログで動作を詳細に見てみることに。

やはり２回呼び出されていて、一回目はgetResultData()は設定されていない状態で、2回目はgetResultData()が設定されている状態でした。

abortBroadcast()させてみたり、マニフェストのandroid:priorityを変えてみましたが、この辺の処理であまり動作を変更したくないので色々と試したところ、getResultData()がセットされていないときに処理を行わないようにしたら動作が落ち着きました。

この状態で手持ちの端末で様子を見ていますが、２回呼び出しが行われているのはSH-M02だけなのでこれがAndroidバージョンによるものなのか、ビルドによるものなのか、もしくは他のアプリが原因かは不明。

FFFTP V3.5でSSL暗号化を有効化したvsftpサーバーへ接続できない

先日PCを入れ替えたのでFFFTPも最新の物をダウンロードして使ってみたのですが、どうも一部のraspbeery piのvsftpへの接続がうまく行かない状況に陥っていました。

原因がはっきりしないままモヤモヤしていました。
完全に接続できない状態ではなく、FFFTPの画面上ではFTP接続した後にディレクトリを受信した状態で完了せず、受信中断以外は何もできない状態になりました。
受信中断ボタンを何度か押すと、ディレクトリが表示され使えるような雰囲気になるのですが、ディレクトリの読み込みタイミングで何度も同じような状況に陥ってしまい使い物にならなくなりました。

ですが、ほかのRaspberry Piへの接続は問題なく行くので、FFFTPが原因だとは思いつつも放置していましたが、また同様の状態になったので、何が違うのか調べてみると、うまく接続できないパターンはvsftpのSSL暗号化を有効にしているものへのアクセスが失敗していました。

ただ不思議なのは、FFFTPのサーバー登録を新規で行って接続するとうまく接続できたことが少なくとも１回はあったので、変なバグが潜んでそうな感じです。
暗号化設定のページでWinSCPというFTPクライアントを使用していたのでそれをダウンロードして使ってみたところ、SSL暗号化を有効にしたvsftpでも問題なく接続できることを確認できました。

https://iotdiyclub.net/raspberry-pi-3-vsftpd-setting-ssl-1/
https://forest.watch.impress.co.jp/library/software/winscp/

ただ、このWinSCPのファイル転送はバイナリモードで行われることを前提としている雰囲気で、転送はできるものの、改行変換は行われない模様。内臓エディタで直接編集できるからいいっちゃいいのかもしれませんけど、ちょっと難ありでした。

私も、バイナリ転送だけでいいんじゃね的な思想の時期もありましたが、今では変換ありも捨てがたいと思っています。万能テキストエディタを使ってればいいんですけど、結局デフォルトのエディタが一番使う機会が多い。

アップデートしたものからもxrdpで接続できるようになりました。が、

すでに10日ほど前の話になってしまいますが、壊れたキーは復活することはなく、ダメ元でシリコンスプレーやらコンプレッサーをつかったりして修理してる気分には浸れましたが、修理というよりトドメを刺しただけでした。

ダメなキーはよりダメに、ダメじゃなかったキーも徐々にダメに。

ダメになっているキーを見てみると格子配線の一本が切れかかってる感じがします。
ダメそうなのはASWEXとかだったかな。

もし水滴などでやられただけなら完全乾燥すれば治りそうな気がしますが、シリコンスプレーを盛大に掛けたので、シート同士がうまく離れなくなって、スイッチとしては機能しなくなると思うので、放置で治るとは思えません。が、それから何度も試してはいます(笑)

本題に戻ると、xrdp経由の接続ではvncサーバーが動いている必要もないというのがようやく実感できました。ですので接続だけならraspi-configのインターフェースでvncを有効にする必要もありません。 ただ、デバイス側のディスプレイが動いていないと問題はありそうな部分もあるので、この辺はまだしっかりと理解できていません。

普通に接続できるようになったraspberry piでも、諸々の設定が昔とは随分と変わっていて、GUIの設定側でユーティリティ経由で起動しているので、物理ディスプレイ（なのかな？）でないと起動しない状態になっていたりするので、xrdp経由で接続できたからといって、まだすべてが満足な状態にはなっていません。

jessieからstratchへアップデートをかけたものは、xrdp経由で接続した後、デスクトップが表示されなかったのですが、動いている環境のパッケージの差異を見つけてアンインストールを繰り返し、ようやくデスクトップが現れるようになりました。

表示されているのですが、いろいろと古い感じがします。

ブラウザはあるにはあったありましたが。

パッケージが全体的に抜け落ちてる感じなのと、もしかしたら、ライト版がもとになってるのかもしれないのかな？

右往左往した軌跡として.bash_historyを見てみました。
sudo apt-get purge realvnc-vnc-server
sudo apt-get autoremove
sudo apt-get autoclean
sudo apt-get install realvnc-vnc-server
sudo raspi-config
sudo apt-get purge realvnc-vnc-server
sudo apt-get autoremove
sudo apt-get purge xrdp
sudo apt-get autoremove
sudo apt-get autoclean
sudo apt-get purge youtube-dl
sudo apt-get purge xserver-xorg-legacy
sudo apt-get purge xserver-xorg-input-evdev
sudo apt-get purge xserver-xorg-input-synaptics
sudo apt-get autoremove
sudo apt-get autoclean
sudo apt-get purge ant
sudo apt-get autoremove
sudo apt-get autoclean
sudo apt-get install realvnc-vnc-server
sudo apt-get install xrdp
sudo apt-get update
sudo apt-get dist-upgrade

リブートするとxrdpがエラーに

ここ数日raspberry piでxrdpでwindowsからリモートデスクトップ接続を使えるようにしたのですが、接続できなくなる状況に陥ってしまい悩んでいました。そもそもの原因が良くわからないので結構手間取っていました。

手持ちののもで接続できない状況が２パターンあるようで、一つは旧バージョンからアップグレードしたもので、xrdp接続後、vncサーバーに接続できないパターン。
もう一つはインストール後は接続でき、再起動後にxrdpへの接続ができず、xrdp自体が起動していないパターン。

一つ目はまだ未解決ですが、二つ目の原因がようやくハッキリしました。

ググってみてようやく見つけたのが
xrdp service fails to start after reboot
https://raspberrypi.stackexchange.com/questions/75892/xrdp-service-fails-to-start-after-reboot

という記事でタイトルがそのものズバリで、回答もそのものズバリなものでした。

回答では「マジでlogをtmpfs使ってるの？」ぐらいな感じですが、原因までしっかりと書かれてて素晴らしいです。
原因としては正しく書き込めるlogファイルが存在しないとエラーで起動しないので、ブート時に

touch /var/log/xrdp.log
chown xrdp:adm /var/log/xrdp.log
chmod 640 /var/log/xrdp.log

という感じのスクリプトを動かせばいいんじゃね？的な感じでした。

現象の把握もしんどかったのですが、原因追及も結構きつかったのですが、わかってしまえば、簡単な話でした。

もう一つのxrdpからvncへの接続が失敗してるパターンはもう万歳してしまいそう。

sqliteのデータ消失

データベースのデータが飛ぶというのは正直シャレにならない感じですが、sqliteで結構な頻度で発生しています。
原因はハッキリしませんが、データファイルがサイズ0になっているわけではなく、ファイルサイズはおそらくそのままで、テーブルが無効化されている感じで、消失したデータファイルにアクセスすることが可能でした。エラーが出ていないだけかもしれませんが。
今のところ分かっているのはデータベースファイルを開いてからもう一つのデータベースファイルをattachしてコピーしてからdetachして閉じた後にattachしたデータベースの内容が消えている場合がありそうだということ。

python 2.7で実行していたので、3.5で実行して様子を見てみよう。

消費期限切れ

明日の朝に食べようと思って買ってきたパンが昨日賞味期限切れでした。

売り場にどう見てももうすぐ値引きシール貼られそうなパンがあったので、めずらしくあえてそっちを選んで買ってきたらコレですよ。
品出しがまともにできていない棚がある場合は、まともなスタッフが不在ということなんでしょう。今までこのお店で購入したもので期限切れのものはなかったので、チェックはしていなかったのですが、これから消費期限に限らず期限日チェックしないとダメだな。

telenetでraspberry piのスクリプトを手直ししていたらエラーがでて少し手間取ったのですが、チェックしてみるとタイプミスによるエラーでした。
例えば hostnameとするべきところを hostnmeとか。
修正しようと「a」を押しても表示されないので、押しなおすと「a」が表示されたのですが、しばらくするとやはり「a」だけ抜けてしまうので、とうとう壊れたかと脱力。
最近のキーボードは漏れなくシートタイプの接点なのですが、この手の接点は直せた試しが無いので調べてみると、一つ前のモデルならキー部分だけ部品交換できそうなのですが、手持ちのモデルではキーボードがピンとなるプラスチックを溶かして固定しているようで、部品も出回っていませんでした。旧モデルの流用はできそうな感じですがキーボードの販売もなさそうなのでどうしようか思案中。

安くて使えそうな10インチノート無いかなぁ…

element14とRS Components

先日キャンセルできなかったRSコンポーネンツ版のRaspberry Pi 3 B+が手元に届いたので落ち着いてから開封して、基盤を見るとRS版の方がすっきりとした印象を受けました。

Raspberry Pi 2BのRS版を見たときはチップが少し踊っていたのでRS製品はあまり良い印象は持っていなかったのですが、3B+を見るときれいに仕上がっています。

ヒートシンクを張り付ける際にチップの厚みがelement版の方が厚い気がしたのですが、ただの気のせいだったのかも。
背面のメモリチップに貼り付けるときにRS版の方が何も気にしなくて張り付けられたのですが、製品写真を比べるとどちらもほぼ差異はなく、基盤のプリントも一緒のような雰囲気。

直接見比べることができそうにないので判断が難しいですが…商品紹介に使われてる写真は加工されてるだけで元が一緒のような気がする。

手元に届いた製品で確実に違っているのはRS版ではボード上のディスプレイ用のコネクタとカメラ用のコネクタにシールが張り付けられているので、全く使用しない方は埃が入りづらくなってていいかも。

発熱温度はチップ内の温度センサーで見比べる限り、どちらも変わらない感じです。

注文キャンセルをしたときは、すでに出荷直前

手持ちのRaspberry 3bのメモリーに貼り付けているヒートシンクを付け替えようかと思ってケースを分解しました。
まず、安全のためにターミナルから、シャットダウンさせ電源を抜きLANケーブルを抜いて上蓋を外して、GPIOに付いたコネクタを抜き、microSDを抜いてから、下の蓋を外しました。
構造上少し余裕がないとはめ込みで当たりそうなので、少し大きめにケースに穴を空けて、すでにとりついている薄い銅板ヒートシンクを剥がして別のアルミ製のヒートシンクを取り付けました。
組み立てなおして電源ケーブルを入れた後、温度を確認したところ、アクセスできない状態に。
RaspberryのLANコネクタは光っているので、またSDが逝ったのかと思いつつももう一度電源を入れ直してみましたがダメみたいです。

何度か電源を入れ直したり、SDを差しなおしましたが状況は変わらず。むしろLANコネクタのランプもつかない状態になってしまい悪化した感じに。
慌ててGPIOも抜いて、ほとんど素の状態にするものの本体の赤いランプしか転倒しない状態に。

RaspberryPiで初の本体ボード故障。

現状に納得できないまま、むき出しの状態のボードを目視チェック。ヒートシンクを取り外すときにチップやチップのハンダが損傷してるのかもしれない。ヒートシンクがボードに取りつつけられているチップのハンダに触れてショートしてしまったのかもしれない。GPIOにぶら下がってるブレットボードを電源が入ったままぶら下げたり結構乱暴に扱っていたので、抜けかけたケーブルがショートしたのかもしれない。
手持ちのSDカードをフォーマットしてHDMIでモニターをつなげたり色々やってみましたが、極まれに緑のランプが点灯したままになったので淡い期待で色々試していました。
理由はいろいろ考えられますが、かなりいい時間になってしまったので横になって気づけばRaspberry piの値段を探っていました。
正直なところあまり過負荷にさせたくないのと、発熱量が少ない方がいいので2Bがいいのですが、Wifiが無いのが厳しいところ。そうなると壊れた3Bがいいのですが、アマゾンで見るとセット売りでどのモデルもいまだに結構高値で売られています。メインメモリが大きければZeroWが一番理想なんですけど、Zeroシリーズですら2000円だと買えないとか。たしかWifiがないZeroって500円っていうイメージがあったのですが、Raspberry関連のアマゾン価格はどうもおかしい。それだけ返品が多いということなんでしょうかね。
返品と言えば日本人は返品というのは海外に比べて少ないらしいですが、レビューを見てると結構返品している人は多いイメージ。しかも説明書きも読まずに「動かない」とか壊れてるとかいう書き込みを多く目にします。raspberryなんてosのzipファイルをダウンロードして適当なsdカードに展開するだけであとはHDMIとUSBキーボードとUSBマウスを差し込んで電源を入れれば何らかの画面が出てくるはずなんですけど、一般的な商品と比べるとかなりの確率で返品されてそう(;´Д｀)

寝落ち直前まで思案して結局ポチらず朝を迎えました。目覚めはかなりやばい状況でした。確実に寝坊。目覚ましも記憶にないし。

その後やはり思案して今日届くであろう液晶を動かしてみたくてスマホからポチって見ました。

昼にダメ元で再度チップを軽く押さえながら電源を入れたりしてましたがもちろん状況は変わらず。そしておもむろにコネクタにCRCを吹きかけたり接点にはあまり関係ないというか、良くない感じのシリコンスプレーも。掃除のためにSDカードを抜き差しを繰り返しながら電源を入れてみると、なんということでしょう。緑のランプがいい感じに点灯、消灯を繰り返し始めました。HDMIケーブルを接続してみると、画面の表示が。

結局、microSDカードコネクタの接点不良が原因だったみたいですね(*´Д｀)
恐る恐るもう少し接点をボール紙などで掃除したり外してしまったヒートシンクにテープを張り付け直して取り付けたりしてセットしてみましたが、いい感じです。もともとのSDカードも問題は無さそうで無事起動できました。

昨日の悪夢は何だったんでしょうか。

あまりアマゾンではキャンセルしたことが無いのですが、問題なさそうなのでまだ出荷されていない注文のキャンセルを押してみると、「キャンセルリクエスト」として取り扱われました。最近アマゾンは着日から逆算して直前になるまで出荷されなかったり、真夜中から明け方にならないと出荷されない感じだったのですが、すでに出荷準備中でキャンセルできない可能性があるという趣旨の内容が表示されました。

そしてメールで「キャンセルリクエストをしていただいていた以下の商品をキャンセルすることができませんでした。」とか。
トドメは、

ご注文いただいた商品を本日、Amazon.co.jp が発送し、ご注文のお手続きが完了しましたので、お知らせいたします。

最近着日の午後にならないと発送のお知らせが届かなかったのですが。キャンセルリクエストすると、せっかくの売り上げを取り消されないように手早く出荷するんでしょうか。

また削除

先日アプリ側の対応したものが再度削除されました。
結局AdMobを利用しているアプリは根本的にダメっぽい気がします。

とりあえずユーザープライバシーについて明記を行って削除が解除されるか、解除されなければAdMobの利用をやめるぐらいでしょうかね。

Google Playストアからのアプリの強制削除

午前5時過ぎ。
半分寝ぼけながらスマホが光ってたので通知を確認するとPlay Consoleアプリからの通知で「アプリが削除されました」という内容の通知が４つ。
正直不意打としか感じない対応ですが、EUの個人情報保護に関する対応なのかなと。

メールを確認すると４つメールが入っていて、内容は同等ので以下の内容でした。

[アプリ]についての通知

デベロッパー各位

審査の結果、 [アプリ] は、Google Play ポリシーに違反していると判断されたため、Google Play ストアから削除されました。このアプリは、ポリシーに準拠するアップデートをご送信いただくまで、ユーザーに配布、販売されなくなりますのでご了承ください。

削除の理由: Android 広告 ID の使用ポリシー及び Google Play デベロッパー販売 / 配布契約 4.8 への違反

アプリが個人情報や個人情報や機密情報を扱う場合、有効なプライバシーポリシーを掲載して頂く必要があります。お客様のアプリは Android 広告 ID の収集及び転送を行うことが確認されましたので、プライバシーポリシーを掲載して頂く必要があります。

アプリが Android 広告 ID の収集を行う場合、有効なプライバシーポリシーを Play コンソールの所定の箇所及びアプリ内に掲載して頂く必要があります。プライバシーポリシーの中でユーザープライバシーについて明記し、URL が有効であることをご確認ください。

必要な対応: プライバシーポリシーをストアの掲載情報及びアプリ内に追加してください

Android 広告 ID の使用に関するポリシー、ユーザーデータに関するポリシー、Google Play デベロッパー販売 / 配布契約を確認し、アプリを修正します。個人情報や機密情報を要求する場合、上記 Google Play ポリシーに準拠した上で、有効なプライバシーポリシーへのリンクをストアの掲載情報及びアプリ内に掲載して頂く必要があります。
アプリが、デベロッパー プログラム ポリシーに含まれるすべてのポリシーに準拠していることを確認します。再度ポリシーに違反したアプリには追加措置が取られることがあります。
デベロッパー コンソールにログインし、ポリシーに準拠した修正済みの APK をアップロードします。必ず APK のバージョン番号を更新してからアップロードを行ってください。

また、お客様のアプリから個人情報や機密情報に関するアクセス権限リクエストを削除していただくことで、今回の警告を回避することも可能です。

アップデートが承認されると、アプリはすべてのインストール、評価、レビューが元のままの状態で再び配布、販売されるようになります。

ポリシーをご確認のうえ、今回の削除措置が誤りだと思われる場合は、お手数ですがポリシーサポートチームまでお問い合わせください。担当者が 2 営業日以内にご連絡いたします。

どうぞよろしくお願いいたします。

Google Play チーム

 句読点の「。」が一か所飛んでるのが気になりましたが、メールをざっくり読んで対応できそうなのは

1. Googleへ文句を言う。
2. アプリを修正する。

のどちらかという感じなのですが、おそらくGoogleへ連絡したところで対応があるとは考えられないのでアプリ修正を寝ぼけながら始めました。今見直すと、ポリシーの掲載だけでも行けそうですね。

現状削除された４つのアプリはAdMobを利用しているアプリで、アナリティクスも利用しているかな？

アナリティクスは、アプリ公開時は実装方法やレスポンスといったアナリティクスに対する興味で実装していたのですが、最近はその興味も全くなくなってしまい、Firebaseに統合されあとは、アプリソース内から関連コードを削除しているのが現状です。
ただ、アナリティクスは他のFirebaseの基本部分として firebase-core という位置付けで自動的に利用している感じはします。

AdMobに関しては、鼻で笑うしかない状態なので削除してしまってもいいんじゃないかと思う一方で、まぁもらえるものは欲しいという欲求のためにだけ使っている感じです。

問題となっている「広告ID」ですが、アプリ内では一切ノータッチです。アナリティクスが間接的に使ってそうな気もしますが、確実にAdMobが利用しているとは思います。

個人情報保護の観点ではアプリにダイアログを表示させて同意させればよかったと思いますが、まぁ…そんな同意がそもそも嫌いなので、利用していない「広告ID」を何とかできないかとググってみるとそれらしいのがありました。

広告IDを使っている覚えがないのにGoogle Playからポリシー違反を通告されたけどFirebaseのせいだった https://qiita.com/Nkzn/items/326ad03e358b5d3fbafc

このまとめっぽい記事内のメールは18日に届いてこれが7日前の警告なのですが、私の手元にはいきなり削除したあとの事後報告メールです。しかも自動(;´∀｀)
ユーザーポリシーの掲載もしていないので、そんなデベロッパーは一斉に削除対象になったんだと思いますが、それでも18日+7日=25日に削除のはずなのに22日に削除するとかね…。

対応方法はメタタグを追加すればよさそうで、この方法は公式のドキュメントにも記載してありました。
そもそも「広告ID」は使用していないので、固定で無効にしておけばいいのでこれだけでOK。

そろそろ真面目にポリシー書いて掲載しておかねばならないのかな(´-ω-`)

対応方法は単純なのですが、問題なのはAdMobを含むアプリで機能的な理由からコンパイルSDKレベルを止めているアプリがあるので、その動作確認をする必要がありました。結果から言えばSDK26でコンパイルしてAndorid 7.0で動作したのでちょっとほっとしました。そもそも非力な端末でなければ必要ないアプリなのでもう出番はないかな？と思っていたのですが、Android Oneのおかげで意外と需要はあるみたいです。

他の物はライブ壁紙とスクリーンセイバーなのでSDKレベルが上がっても大丈夫かなと判断して最新の28でビルドし直して終了。

書けばたったこれだけなのですが、実際の作業は結構壁にぶつかりながらの作業でした。
Gradleのバージョンが上がってしまったための対応だとか、firebaseのライブラリのバージョンアップの対応とか、Android Studioのバージョンアップの対応とか。
ソースコードはほぼ変更していないのですが、.gradleの書き換え作業が面倒で何が引っかかってるのかわかり辛すぎました。

まぁこんなことが無い限り最近は製品版のリリースは行わないで、内部トラックでしかリリースしてませんけどね(;´∀｀)

・また削除