ぷろじぇくと、みすじら。

U-NEXT TV (第二世代)はAndroidおもちゃではない

Created at:

U-NEXT、9,800円のHDR対応Android TV「U-NEXT TV」。カラオケやYouTubeも - AV Watchという記事を見て「先着100名で、新規にU-NEXT登録した人を対象にU-NEXT TVをプレゼントするキャンペーン」とあったので登録してみたところ無事届きました。というわけでAndroidとして遊べないかなというところに関してのお話です。

製品仕様はキャンペーンサイトに書いてあり、Android 7.0であることが明記されています。

U-NEXT TV (2nd Gen)

端末自体はHuaweiです。この手のセットトップボックスではHuawei製はよくあるようです(たしかauやdocomoのものもそうだったはず)。

OS

さて、Androidに関してですがよく見ると公式サイトの製品仕様にはAndroid 7.0とはあるもののAndroid TVとは書いていないのでもしかしたら…と思っていたのですがセットアップし始めるとやはりAndroid TVではなく単なるAndroidです。

そもそもセットアップステップがAndroid TV風でなくU-NEXTのログインが必須であったり、オンスクリーンキーボードもAndroid TVのそれではない、ホーム画面は独自というあたりでお察しです。

製品仕様によればアプリも利用できることになっているのですがAndroidがベースになっているだけでGoogleサービスが入っていないのでGoogle Playは使えません。「U-NEXTサービス、HDMI-CEC対応、Player for YouTube、Androidなど」とあるので使えるのかと思いきや。

YouTubeを観れそうな雰囲気ですがGoogle Play入ってないのにどうやって?と思ったらHuaweiの独自アプリでした。oh…。

現状U-NEXT用のアプリストアがあるわけでもないのでプレインストールのアプリのみ利用できます。なお設定のアプリ管理からアプリをアンインストールできるのですが、それらはインストールする口がないので消したら最後です(これはひどい。

参考までにほぼ同型機のdocomoのドコモテレビターミナルは説明書を見てもわかるのですが正真正銘のAndroid TVでロゴも表記されています。

adbを使う

とはいえAndroidなのでUSBデバッグとかできればなんかいろいろできるかもということで探すとちゃんとUSBデバッグはあります。

「アプリ」→「端末設定」→「情報」→「開発者オプション」→「USBデバッグ」で有効になるので有効にして、USBケーブルをつなぐと許可するかどうかのダイアログが表示されます。ちなみにUSBケーブルはType-Aなので注意が必要です。

接続後はいつものようにadbでコマンドを実行できshellにも入れます。そこで早速apkをインストールしてみようとすると次のようなエラーが発生しました。

adb -s 0123456789 install "app-release.apk"
adb: failed to install app-release.apk: Failure [INSTALL_FAILED_UPDATE_INCOMPATIBLE: Verify signature failed]

どうも署名チェックのようなものがあり、そこで引っかかっているようです。

提供元不明のアプリのインストールを許可する必要があるのか?と思ったので設定画面を開いてセキュリティから許可してみましたがダメです。Webを検索してもそれらしい情報はないので端末固有でロックをかけていそうです。うーん。

なお、設定画面は am コマンドを使えば開けます。

$ am start -a android.intent.action.MAIN -n com.android.settings/.Settings

ちなみにバージョン情報はこんな感じです。

もう少し探ってみたところ /system/etc/security/apk_sign_white_list.xml というファイルがあり、署名のホワイトリストのようなものだったのでユーザーが任意にインストールするのは無理そうですね(HuaweiやU-NEXTだけが含まれている)。

一応 pm list packageの結果、パッケージの一覧はこんな感じでした。

まとめ

残念ながらAndroid端末としてはいじりがいがないのでそこを期待してはダメそうです。とはいえ特定サービス向けの装置なのでそこはしょうがないかなーという気もします。

U-NEXTのSTBとしてはきびきび動いたりするので普通に使う分には割とよいのではないかとは思いますが、実際お金を出す場合半額の4,980円でもどうかなー…って感じがしますね。リテラシがなくてつなげば使えるみたいなのを求めていない限り、正直縛りのないAndroid TVであるAirStick 4Kの方がよさそう。

そうそう、ログイン必須なので退会すると完全に使い物にならなくなります。

App Centerでユーザー定義環境変数を取得できない

Created at:

Visual Studio App Centerではビルド時の環境変数を定義でき、ビルドスクリプトやGradleのようなビルドシステムから値を取得できるのですが、定義しても環境変数が取れないという現象が発生しました。

tl;dr

SECRET のようなApp Centerが許可しないキーワードを含んだ環境変数を定義している場合、そのままの名前で露出しないようになっているようです。PASSWORD のような単語は通るので SECRET のみの制限かもしれません(ドキュメントに特に書いてない)。

ユーザー定義の環境変数は USER-DEFINED_ というプレフィックスがついた環境変数も定義されるのでそちらから取得する方法もありますが、ハイフンを含んでいるため参照も定義も一筋縄ではいかないのでお勧めできません。

問題と調査

API_KEYNUGET_USERNAME のような環境変数を定義してみたところ特に問題なく取得できたので、もしかして変数名に問題があるのでは?と思いいくつかのパターンを試してみました。すると以下のパターンで違いが出ることがわかりました。

この定義を設定した上でビルドし、pre-buildスクリプトで環境変数をすべて出力すると…

##[section]Starting: Pre Build Script
==============================================================================
Task         : Shell Script
Description  : Run a shell script using bash
Version      : 2.1.3
Author       : Microsoft Corporation
Help         : [More Information](https://go.microsoft.com/fwlink/?LinkID=613738)
==============================================================================
[command]/bin/bash /Users/vsts/agent/2.127.0/work/1/s/app/appcenter-pre-build.sh
...snip...
SECRE__HAUHAU=hauhau3
...snip...
USER-DEFINED_SEECRET_HAUHAU=hauhau2
...snip...
USER-DEFINED_SECRE__HAUHAU=hauhau3
...snip...
USER-DEFINED_SECRET_HAUHAU=hauhau1
...snip...
SEECRET_HAUHAU=hauhau2
...snip...

…となり、SECRET_HAUHAU という変数のみそのまま露出しないようになっています。この結果からApp Centerは SECRET を含む環境変数をそのまま変数として露出しないようにしているようです。セキュリティのためでしょうか。

というわけで特別必要がなければ SECRET という名前を含めないでおくというのがハマらないポイントです。

App Centerでビルドスクリプトが動かない

Created at:

Visual Studio App Centerでビルドする際、特定の名前でシェルスクリプトを置いておくことでビルドの前後でコマンドを実行できます。

2018年2月時点では Build scripts | Microsoft Doc にある通り、以下のスクリプトを認識します(for UWPなら.ps1)。

ここまでは書いてある通りなのですが、実際リポジトリにビルドスクリプトを含めても一向に実行されないという問題が発生しました。設定画面を見ると Build scripts: ✔ Post-clone と表示され認識はされているようでした。

新しいブランチを作ってビルド設定を追加して試すと問題なく動作したので悩んだのですが、実は Build scripts: ✔ Post-clone となった後に Save もしくは Save & Build で設定を保存する必要があるようです。

逆を言うと、ビルドスクリプトを削除した後も保存しなおさないとビルドがエラーになります。

新しいブランチを作った時に動いたのは、すでにビルドスクリプトが含まれていて、ビルド定義を作る際に Build scripts: ✔ Post-clone となった状態だったからということでした。

TiarraのIRCログをBigQueryに流し込む

Created at:

ふとTiarraでとったIRCのログをBigQueryに流し込むようにしたら手元にログを長期間残す必要もないし、検索もできるし便利そうだなと思ったので設定してみました。Twitterのログもあって若干流れますがBigQuery的には誤差の範囲レベル(1日1MB程度)なのでStreaming Insertして、たまーに検索しても無料枠で余裕で収まりそうです。

主な流れはTiarraで吐いたテキストログをfluentdのin_tailで読んで、fluent-plugin-bigqueryでBigQueryに流し込むという何の変哲もない形です。

Docker

ですでに手元のTiarraはDocker(docker-compose)で起動しているのでfluentdもDockerで起動しています。fluent-plugin-bigqueryはfluentdの公式イメージに追加する必要があるので適当に追加します。

FROM fluent/fluentd

RUN apk --no-cache --update add ruby-bigdecimal ruby-dev build-base && \
    fluent-gem install fluent-plugin-bigquery

ruby-bigdecimalが必要ということはREADMEにあるのですが、ruby-devとbuild-baseも必要で追加していないとfluent-plugin-bigqueryをインストール中にstrptimeのビルドで失敗します。

BigQuery Schema (schema.json)

次にBigQueryのスキーマを用意します。今回は次のようなものになっています。

[
    { "name": "Time", "type": "TIMESTAMP" },
    { "name": "User", "type": "STRING" },
    { "name": "Server", "type": "STRING" },
    { "name": "Room", "type": "STRING" },
    { "name": "Text", "type": "STRING" }
]

テーブル自体はこのスキーマを使ってfluent-plugin-bigqueryに自動生成させるので、BigQuery側にはプロジェクトとデータセットだけ作っておきます。このスキーマファイルは次のfluent.confと同じところにおいてください(最終的にdockerでマウントされるところ)。

fluentd (fluent.conf)

最後にfluentdの設定です。

source(入力)はssig33 - Tiarra のログを fluentd で流すを参考にin_tailを設定します。手元ではTIGのログが流れてくるのとサーバー名を分解するために少し変更しています。ログはローテートされるので %Y.%m.%d.txt で。

出力はfluent-plugin-bigqueryの設定を auto_create_table で設定します。これ自体は何のことはない設定なのですが table を年で分けるようにしようとしたところでハマりました。

table にはプレースホルダ文字列を使えることになっているのですが、文字列置換が有効になる条件としてまず buffer time/timekey を設定しているというものがあります。そこで timekey を設定すると %Y ではなく %d 精度のプレースホルダを持つ設定を要求します(参考: output.rb)。しかし今回は%Yでいいのに…困った…と考えた末に fetch_schema_table という使っていない設定項目に log_%Y%m%d 入れて回避しました。

とはいえ真面目にBigQueryを使うレベルなら日別にすると思うので(扱いづらいし…)罠にははまらないとは思います。日付パーティションにしてもいいかもとか頭をよぎりますが量も大してないので最悪あとで何とかすればいいでしょう(適当。

<source>
    @type tail
    path /fluentd/log/tig/tig-twitter/%Y.%m.%d.txt,/fluentd/log/ircnet/*/%Y.%m.%d.txt,/fluentd/log/freenode/*/%Y.%m.%d.txt
    tag tiarra

    format /^(?<time>[^ ]+)\ (<(?<room>[^ ]*)@(?<server>[^ ]*):(?<user>[^ ]*)>|\((?<room>[^ ]*)@(?<server>[^ ]*):(?<user>[^ ]*)\)|>(?<room>[^ ]*)@(?<server>[^ ]*):(?<user>[^ ]*)<|-(?<user>[^ ]*)-|>(?<user>[^ ]*)@[^ ]*<)\ (?<text>.*?)(?: \u0003\d+\([^)]+\).*)?$/
    time_format %H:%M:%S
</source>

<match tiarra>
    @type bigquery

    method insert

    auth_method json_key
    json_key /fluentd/etc/serviceaccount_key.json

    project <YourProjectName>
    dataset <YourDataSetName>
    table Log_%Y

    auto_create_table true
    schema_path /fluentd/etc/schema.json

    # table でplaceholderを使うために必要
    # buffer time/timekeyの設定が必要でそのためにplaceholderの%dをもつ設定が必要なので使わない項目をダミーとして使う…
    fetch_schema_table log_%Y%m%d

    <buffer time>
        timekey 1d
    </buffer>
    <inject>
        time_key time
        time_type string
        time_format %s
    </inject>
</match>

あとはこれでfluent/fluentd-docker-imageを参考にDockerでマウントしつつ起動すればログがBigQueryに良しなに送られます。便利。

TP-Link Deco M5

Created at:

Deco M5

以前からWi-Fiの電波の届き具合があまりよくないなと感じていて、アクセスポイントもAterm WR8500Nなので10年前のものだし、それ一台(途中で中継器を足したけど)で一軒家をカバーするのもまあ厳しいしもういい加減変えてもいいでしょう…。ということで、電波の届き具合で悩んだのでやはりここはメッシュWi-Fiにしてみようと思いTP-Link Decoを設置しました。

メッシュWi-Fiは一つのネットワークを複数のユニットでいい感じにカバーする仕組みらしいです(雑な説明)。まあ賢いローミングシステムをお手軽に構築できるものって感じでしょうか。Google Wi-Fiなどもこの手の製品ですね。Decoはスターターキットとして3つのユニットがセットになっています。

とはいえ個人的にはTP-Linkにはいろいろ思うところがあり、C5400を買ったときのメモを見ていただくとお察しいただけるかと思いますがブリッジモード(APモード)ではまった経験と最近話題のNTPサーバーへのアクセスの件もあって、正直心象はよくなかったのですが選択できる製品もあまりなく。あとから調べたらASUSのWi-Fi ルーターは組み合わせてメッシュを組めるとか…でもEthernet Backhaul相当があるのかはわからないですね。NETGEARのOrbiは2+1だとちょっとお高いです。

実際設置してどうだったのかというと安定のTP-Linkクオリティです(ほめていない)。今回もまたブリッジモード(APモード)で設定したのですが、とにかくちゃんと設定して安定して動くまでが怪しい…。

怪しかったのは次のようなところ。

良かったところは設定の手順自体は簡単だったり、ネットワークが安定すれば切り替えもまあまあスムーズだし、Backhaulしているおかげでどこにつないでも速度が出るというあたりでしょうか。C5400の時と同じで一度動けばWi-Fiは優秀みたいな…。

なんというかTP-Linkのルーターのブリッジモードはやっぱりやめた方がいいんじゃないかというのを改めて感じますね。Ethernet Backhaulせず、ルーターモードで使う分にはサクッとネットワークを組み立てられそうですが、ブリッジモードはある程度苦労を覚悟することをお勧めします。

まあとりあえず電波が家中に届くようになってなんとなく動いているので結果オーライということで。

追記(2018-01-03): どうやらEthernet Backhaulが鬼門らしく、ブリッジモードでEthernet Backhaulを有効にしたDecoユニットを追加すると謎の再起動や参加失敗(オフライン扱いになったり消えたりする)が発生するのでEthernet Backhaulを一旦諦めました。詳しくは検証していないのですがどうもスイッチと相性が悪い場合に似たようなことが発生するらしくそれかもしれません。

フォーラムの書き込みによるとD-Linkの一部スイッチはIEEE1905.1 プロトコルをうまく通さないため問題(リブートループ)が出る場合があるという話があり、D-Linkのスイッチではないものの手元も似たような現象なので原因は同じかもしれません。もし不安定なようであればスイッチを外してEthernet Backhaulを試していくのがよいようです。