2018年1月14日日曜日

Xperia XZ,X Performance 向けOreo用カスタムカーネルを作成する。

 しばらくぶりの投稿になります。
 自分は現在のところF8132(Xperia X Performance)を使用しています。
カスタムカーネルとしては長らくAndroplus Kernelにお世話になってきましたが、Oreo用のカーネルはリリースされずサポート完了になってしまいました(恐らくメインの活動場所が他の端末になったためと、この記事の途中でも詳述しますが、コンパイルに失敗するためだと思います)。

 という訳でしばらくはXDAに投稿されたパッチ済みのStockカーネルを使っていましたが、せっかくだから前にもカーネルコンパイルまではやってみたことから出来るところまで対応してみようと思い今回カーネル開発をやってみました。
 当然初心者ですが、自分のデバイスをいじる権利(=Bootloader Unlock済み、もちろんメーカにはクレームは出せず自己責任ですが)は持っていることだし知識を増やす意味でやってみました。

注意)

カスタムカーネルのインストールにはブートローダーアンロックが必要になります(この時点で国内キャリア版は使えません。)
 また、カスタムカーネルで実現できる制御範囲はStockよりも多岐に亘りますが、これは必ずしも行うべきというわけではなく、大概はStockのチューニングでも実現可能です。
 また、カスタムカーネルの自作時は当然ながら通常のModと比較し、端末の不動作(ブートループ)に接する場合が高くなりますのでご注意下さい(誤ったカーネルをインストールした場合、最悪ハードブリックして起動出来なくなります)。

1)必須なもの

とりあえずカーネルを自己満足でコンパイルしてboot.imgをビルドするには、これだけあればOKです。

  • PCによる開発環境
カスタムカーネルをコンパイルするためのPC。OSがWindows環境の場合、BusyBoxやVMWareなどで仮想環境が必要だと思います(私の場合はメインの環境がLinux Mint 18.3のためそのまま実行)。

  • SonyMobileのオープンソースファイル
(最新版は1月14日現在、41.3.A.2.24)Open source archive for 41.3.A.2.24

  • クロスツールチェインのコンパイラ

PCでスマホCPU向けにカーネルをコンパイルします。これをクロスツールチェインという。
AOSP(Andorid Open Source Project)・Linaro(ARM界隈の業界団体)なども開発環境を提供していますが、Androplus Kernelほかカスタムカーネル界隈でよく使われているUBERTCをダウンロードして試用しました。
(実はAOSP版も動かしてみたのですが、たまたまリンカがないせいか最後まで生成できないので断念)

本来はXperifirmでダウンロードしたFTFイメージから抽出したStockカーネルイメージ(elfファイル)を解体してFlashtoolで書込み出来るように(+root化の際に必要なパッチを当てる)ツールですが、今回はカーネル本体作成後に必要なもの (ramdiskイメージ)を作成+root化する際に無効化するパッチ当てするのにこれを使用しました。
上記のrootkernelと同じ動作を行うためのものですが、現状ではこれ生成したinitdイメージでの起動は失敗しています(詳細は今後よく検証したいと思います)。
なら何に使用するかというと、既に作成済みのboot.imgを解凍して生成パラメータやinitdイメージなどを抽出することが可能なツールがあるからです。

2)深入りするために必要なもの

前項ではstockカーネルから直接boot.imgを作成できる環境について説明しましたが、せっかくカスタムカーネル作るならば、以下のものも用意しましょう。
githubにあるものをZIPダウンロードかgit cloneでダウンロードします(gitでダウンロード後はリポジトリを41.3.A.2.24_r2に変更してください)。
ただし、先述の通り2つの理由でこのままではコンパイルに失敗します。
一つはソールコードのマージ中に依存関係がおかしくなったせいか”drivers/clk/msm/clock-cpu-8996.c”でコンパイル失敗します。
もう一つはPushリクエストにあり今回のリポジトリで反映されたBluetooth関連のソースコードがStockと互換性がないためそのままではコンパイルが通りません。
  • ソースコードなどを並列比較表示可能なソフトウェア
LinuxではMeldというツールが有り、私はこれを使用しています。
このツール、ファイル単位の比較だけではなくディレクトリ単位での比較も可能なため、StockとAndroplusのソースコードをツリー毎比較する用途などで活用しました。
また、3つのソースでの比較も可能なため、オリジナル・変更中・引用元等複数並べて表示も可能です。

3)一連の流れ

基本的には以下の流れとなります。
  • クロスツールチェインのインストール
  • Stockソースコードのダウンロードと解凍
  • カーネルのビルド(まずはStockから変更せず)
  • Androplusカーネルからのソースコード移植
  • カーネルのビルド(パッチ当てしたもの)
  • ftfファイルからStockのramdiskを抽出→root向けパッチ当て
  • 改変ramdiskと生成カーネルからboot.img生成
  • 生成したboot.imgを端末に書込み+DRMfixのzipを書込み

4)準備

  • クロスツールチェインをインストール
自分のホームディレクトリ配下にtoolchainなどのフォルダを作って解凍すればOKです。
  • Stockソースコードを解凍
Linuxカーネル以外にもいろいろ入っていますが、とりあえずはkernel以外は不要のようです。
Androplusカーネルディレクトリ直下にあるbuild_dora_dsds(doraの部分にはkaguraとなっているものもある。doraはX Performanceを、kaguraはXZを示す)をテキストエディタで開くか、Githubで表示してください。
過去のバージョンにはなりますが、Androplusの開発者はこの記述を行ってカーネルをビルドすることが出来た形になります。最後のブートイメージの作成以外はほぼこの方法で間違いありません。
カーネル開発に慣れているならやらなくてもいいですが、初めての場合は先に開いたbuild_dora_dsdsの記述方法に基づいてout/arch/arm64/boot配下にImage.gz-dtbが生成されているまでをやってみてください。
このときポイントとなる設定/コマンドは以下のとおりです
export ARCH=arm64
→ARCHという環境変数にarm64設定(この環境はarmの64bitであることを示します)
export PATH=~/aarch64-linux-android-4.9-kernel/bin/:$PATH
→ツールチェインのbinディレクトリを環境変数PATHに追加(本例ではホームディレクトリ下のaarch64-linux-andoid-4.9-kernelに配置。これでmakeコマンドが自動的にコンパイラなどをツールチェインから呼び出し出来るようになります)。当然ツールチェインの実配置場所に応じて変更してください。
export CROSS_COMPILE=aarch64-linux-anroid-
→環境変数CROSS_COMPILE(カーネルコンパイル時に使用するツールチェインの各ツール呼び出し前の接頭句になります)をaarch64-linux-anroid-に設定(これはツールチェインのbinディレクトリ内のファイル名を見て確認してください。)
export KBUILD_DIFFCONFIG=dora_diffconfig
→環境変数KBUILD_DIFFCONFIGにdora_diffconfigに指定します。(dora_diffconfigにはコードネームdora向けの専用カーネル設定が記載されているのでそれを指定する。当然自分の作りたいコードネームにここは変更)
make msm-perf_defconfig O=./out
.configファイル(カーネルをビルドするためのコンフィグファイル)を生成する。出力先はカーネルソースの下にoutというディレクトリを生成しそこになる。
make O=./out
カーネルをコンパイルする。Stockの場合はツールチェインがおかしくなければ最後にこのようなメッセージが表示されて out/arch/arm64/boot/Image.gz-dtbファイルが生成されているはずで、カーネルのビルドに成功したことになります(XDAなどで記載されている情報を見る限り、X Performance やXZが使用しているカーネルバージョン3.18の場合GCCのバージョンが4.9より新しい場合はそのままではコンパイル失敗するようです。と言う訳でUBERCの4.9が最適と思われる)。

  LINK    vmlinux
  LD      vmlinux.o
  MODPOST vmlinux.o
  GEN     .version
  CHK     include/generated/compile.h
  UPD     include/generated/compile.h
  CC      init/version.o
  LD      init/built-in.o
  KSYM    .tmp_kallsyms1.o
  KSYM    .tmp_kallsyms2.o
  LD      vmlinux
  SORTEX  vmlinux
  SYSMAP  System.map
../arch/arm64/boot/Makefile:46: 警告: ターゲット 'arch/arm64/boot/Image-dtb' のためのレシピを置き換えます
../arch/arm64/boot/Makefile:33: 警告: ターゲット 'arch/arm64/boot/Image-dtb' のための古いレシピは無視されます
  OBJCOPY arch/arm64/boot/Image
  GZIP    arch/arm64/boot/Image.gz
  DTC     arch/arm64/boot/dts/qcom/msm8996-v3-tone-dora_generic.dtb
  DTC     arch/arm64/boot/dts/qcom/msm8996-v3.0-pmi8996-tone-dora_generic.dtb
  DTC     arch/arm64/boot/dts/qcom/msm8996-v3-pmi8996-tone-dora_generic.dtb
  DTC     arch/arm64/boot/dts/qcom/msm8996-v3.0-tone-dora_generic.dtb
  CAT     arch/arm64/boot/Image.gz-dtb
  Building modules, stage 2.
  MODPOST 0 modules
make[1]: ディレクトリ 'out' から出ます

上記のメッセージでちょっと注目して欲しいのは"GZIP arch/arm64/boot/Image.gz"以降の数行です。
前にPCでandroid端末のKernelビルドした方は気づくと思いますが、見慣れない DTCというものが出ているかと思います。
 これはARM向けのLinuxではDTBという形で対象ハードウェアの構成をカーネルコンパイルの際のファイルとして添付する構造のようです。また、Oreo以降ではこのDTBを使用したdm-verityによる/systemディレクトリ改変防止機能が動作しています
(これの解除方法は後ほど説明します)。

5)Anroplusカーネルのソースコードを移植

AndroplusカーネルからのソースコードをStockに移植します。Meldなどで開発対象のソースとダウンロード済みのAndroplusカーネルのソースを比較表示すると分かりやすいでしょう。
(先の説明通り、Androplusカーネルをそのままコンパイルすると何故か失敗します。Meldで差分を見ても、当該箇所は特におかしくないのでこの方法しかないかもしれません)。
  • Makefileのコンパイル設定最適化(ARMのアーキテクチャーに合わせ最適化します。)
Makefile(修正)
  • dm-verity向けの/systemパテーションチェックを無効化
(先のrootkernelツールでは強引に解凍したカーネルイメージのバイナリを書き換えていますが、カーネルコンパイル場合はソースコードを書き換えればその必要はなくなります)
arch/arm/boot/dts/qcom/
 msm8996-tone-common.dtsi(修正)
→46行目の fsmgr_flags = "wait,verify"; を fsmgr_flags = "wait"; に修正
  • 旧バージョンのAndroplusカーネルから共用コンフィグの差分を入手
githubのBranchを41.2.A.7.76(一つ前)に戻し、arch/arm64/configs/diffconfig/common_diffconfigから160行以降を複写して追加する。
このとき注意して欲しいのは、追加した設定のうち237〜241行のf2fs関連のものは現状のソースコードでは動作しないため、コメントアウトで無効化するか、下記の方法でコンパイルが通るようにする必要があります。
  • IOスケジューラ(fiops・sioを追加)
block/
 Kconfig.iosched (修正)
 Makefile(修正)
 fiops-iosched.c(複写)
 sio-iosched.c(複写)
  • 各種プロセッサのスケジューラ
CPU向けにalucard・darkness・nightmareスケジューラの追加、GPU向けにmsm_adreno_tzを修正+simpleondemandスケジューラを追加
drivers/base/
 power/
  main.c(修正)
  wakeup.c(修正)
 cpufreq/
  Kconfig(修正)
  Makefile(修正)
  cpufreq_alucard.c(複写)
  cpufreq_darkness.c(複写)
  cpufreq_governor.c(修正)
  cpufreq_nightmare.c(複写)
  qcom-cpufreq.c(修正)
 devfreq/
  devfreq.c(修正)
  governor_msm_adreno_tz.c(修正)
  governor_simpleondemand.c(修正)
include/linux/
 cpufreq.h(修正)
  • タッチパネル
マルチタッチ関連 普通にマルチタッチは動作しているので私はインストールしていません
drivers/input/touchscreen/
 clearpad_core.c(修正)
  • videoエンコード・デコードドライバのデバッグ設定off
drivers/media/platform/msm/vidc/
 msm_vidc_debug.c(修正)
  • mmc(SDカード)
モジュールロード時のパーミッション設定(私はインストールしていません)
drivers/mmc/core/
 core.c(修正)
  • qualcommのSoCに関する状態を通知する?+デバッグ表示off
drivers/soc/qcom/
 Kconfig(修正)
 Makefile(修正)
 mpm-of.c(修正)
 state_notifier.c(複写)
include/linux/
 display_state.h(複写)
 state_notifier.h(複写)
  • USB-hidドライバ
キーボード・マウス設定(私はインストールしていません)
drivers/usb/gadget/function/
 f_fs.c(修正)
 f_hid.c(修正)
 f_hid.h(複写)
 f_hid_android_keyboard.c(複写)
 f_hid_android_mouse.c(複写)
 Makefile(修正)
 android.c(修正)
  • KCALドライバ(カーネルレベルで画面の色調を変更)
drivers/video/msm/mdss/
 Kconfig(修正)
 Makefile(修正)
 mdss_dsi.c(修正)
 mdss_dsi_host.c(修正)
 mdss_dsi_panel.c(修正)
 mdss_edp.c(修正)
 mdss_fb.c(修正)
 mdss_mdp_kcal_ctrl.c(複写)
 mdss_mdp_pp_cache_config.c(修正)
  • f2fsサポート
fs/f2fs/data.c
 そのままコンパイルすると1304:12: error: redefinition of 'get_data_block_bmap'と表示されてエラーとなります。これはget_data_block_bmapが再定義されているという意味なので、1304行目以降のこの関数を無効化すればコンパイルは通ります。
(ただし動作は未確認)
  • Safety-Netバイパス関連
fs/proc/
 cmdline.c(修正)
  • カーネルモジュールのバージョンチェック除外?(私はインストールしていません)
kernel/
 module.c
KSM(Kernel Samepage Merge)のデフォルト動作停止
mm/
 ksm.c
  • Bluetooth関連のパッチ(現バージョンではpull requestでパッチが当たっていますが、そのままだとコンパイルが通りません)
net/bluetooth/
 l2cap_core.c
(Androplus Kernelのソースでは3544行と3545行に同じ語句が続いているので3545行を消す。また、3546行の", endptr - ptr"を消す。)
  • 許可されたTCP輻輳制御アルゴリズムを上書きする(TCPアルゴリズム切替時に有効
net/ipv4/sysctl_net_ipv4.c(修正)
  • 802.11で変更無しでキーを再インストールするパッチ
以下の記述を見てパッチ当て)
net/mac80211/
 key.c(修正)
  • selinuxの設定?(私はインストールしていません)
security/selinux/
 selinuxfx.c

6)カーネルのコンパイル+生成

先の準備の方法でカーネルをコンパイルします。先に散々書いてしまいましたができれば少しづつ移植したほうが確実にコンパイルが通ると思います。

7)ftfファイルよりカーネルイメージを抽出→ramdiskファイルのパッチあて→ramdisk抽出+bootimg生成用のパラメータ導出

  1. ftfファイルよりkernel.sin抽出 
    flashtoolで取り扱うftfファイルには当然ファームウェアのアップデートに必要なシステムデータが全て含まれており、その中にはカーネルイメージも有ります。
    ftfファイルは拡張子が.ftfですが、単純なzipファイルのため、これをzipに修正して適当なアーカイバーから解凍しkernel.sinというファイルを抽出します。
  2. kernel.sinからkernel.elfを抽出
    次に、kernel.sinファイルからelfファイルを抽出します。
    これはflashtoolで行います。Tools->Sin Editor で開くダイアログで先程抽出したsinファイルを指定した後、Extract dataボタンを押してelfファイルを抽出します。
  3. kernel.elfファイルでrootカーネル向けのパッチ当て
    rootkernel.shを実行し、kernel.elfから一旦パッチ当て済みのStock.imgを作成します。(これを直接焼いた場合はStockカーネルでパッチ済みとなります)
    先のkernel.elfからboot.imgを生成するコマンドは以下のとおりです。
    bash rootkernel.sh kernel.24.elf boot.img
  4. root用boot.imgからramdiskファイルを抽出
    ストックカーネルのboot.imgからramdiskの圧縮データを抽出します。
    使うのはbuild_tools_xperia/のtoolsにあるunpackbootimgを使用します。
    入力ファイルをboot.img、出力先をwork2にした場合、以下のコマンドで抽出します(ただしOreoのdtbファイルはカーネルと一緒に圧縮されているため分離出来ないようです)。
    ./tools/unpackbootimg -i boot.img -o work2
    出力先には色々なファイルが一緒に生成されますが、そのうち以下のテキストファイルを確認してください(各ファイルに記録された値は、下の"--"に続く文字列、mkbootimgのパラメータに対応する)。
boot.img-base --base
boot.img-board --board
boot.img-cmdline --cmdline
boot.img-kerneloff --kernel_offset
boot.img-pagesize --pagesize
boot.img-ramdikoff --ramdisk_offset
boot.img-secondoff --second_offset
boot.img-tagsoff --tags_offset

8)boot.imgの最終生成

最後に先のコマンドで生成されたramdiskとカーネルデータからboot.imgを生成
この時に使用するコマンドはbuild_tools_xperia/のtoolsにあるmkbootimgを使用します。先に説明したbuild_dora_dsdsと記述方法は一緒ですが、パラメータがOreoでは異なっています。
以下に私が製作に成功したmkbootimgの指定パラメータを掲載します。

mkbootimg --kernel out/arch/arm64/boot/Image.gz-dtb \--ramdisk boot.img-ramdisk.gz \--cmdline "androidboot.hardware=qcom user_debug=31 msm_rtb.filter=0x237 ehci-hcd.park=3 lpm_levels.sleep_disabled=1 cma=32M@0-0xffffffff coherent_pool=2M zram.backend=z3fold" \--pagesize 4096 \--ramdisk_offset 0x82200000 \--tags_offset 0x00000100 \--kernel_offset 0x00008000 \--second_offset 0x00f00000 \--output boot.img

9)boot.imgの端末への書込み

あとは最後です。生成したboot.imgをfastbootコマンドで端末に焼き込みし、実際に動作するかの確認になります。
 ただし、起動前にtwrpに起動し、かならずdrmパッチを/system領域に書き込まないとDRM関連のエラーが発生します。
 msm8996の他のマシーンのカスタムカーネルからソースコードを移植するのも有りかと思います。
 私はAndroplusカーネルの最近のビルドでは無効化されていたcore_ctlを復活させて使ってみています。X Performanceの場合、big×2+LITTLE×2の構成ですが、普段LITTLEだけを動作させて重い処理を行う場合はbigを起こすほうがバッテリ持ちは明らかに良いと思います。

2016年2月20日土曜日

Leafletと国土地理院データで地図情報システムを安価に作成する(その1

はじめに

普通にインターネット上で地図を参照する場合、最王手のGoogle Mapをお使いの方も沢山居ると思います。
このGoogle Map、自分でJavaScriptでコードを記載することで標準のMapを超える機能を実装することが可能です(Google Maps APIという)。
例えば、XMLファイルとしてデータを事前作成しておくことで、地図上の指定座標箇所にマーカを配置したり、サイト上に作成したフォームから住所を入力することで座標を計算して地図をその場所に移動させることも可能です。
ただし、Googleが提供するこのAPI、無償版はアクセス数が限られており、さらにインターネット上で作成された成果物を公開がされていることが条件となります。
例えば自社の設備が配置されている場所を表示したいが社外には当然見せたくない場合などはライセンス登録が必要で、なんと年間120万円〜もします。ちょっと中小企業でGISを使いたいニーズには厳しいですよね。
というわけで、今回は地図・JavaScriptのライブラリ共に公開されているもので同等の機能を持つもののうち、地図には国土地理院のタイルを、ライブラリにはオープンソースのLeafletを使ったものをご紹介していきます。

国土地理院地図について

国土地理院では以下のURLで地理院で管理している地図を用いたサイトを運用しております。この地図データを使用するにあたっては規約はありますが、ほぼ通常の使用では問題ない内容が書かれています。
地理院地図

Leafletとは?

JavaScriptを利用した地図情報サイトを作成するためのライブラリです。国土地理院のサイトにはその他にもOpenLayersというライブラリを用いたものがございますが、個人的に使用した限りではLeafletの方が軽く感じること、さらに海外の大手サイトでも使用実績があること(FOURSQUARE・EVERNOTEなど)、ドキュメントサイトやサンプルが揃っておりわかりやすいことから今回紹介します。
Leaflet - a JavaScript library for interactive maps

地図情報サイトの骨格について

国土地理院サイトに「地理院タイルを用いたサイト構築サンプル集」があり、この中にLeafletを用いたサンプルがあります。
さらに、Leafletを用いたサンプル地図サイトの下にソースへ誘導するリンク(GitHub)があり、この中を見ると直接書き込んだJavaScriptは以下の数行だけです。
var map = L.map('map');
L.tileLayer('http://cyberjapandata.gsi.go.jp/xyz/std/{z}/{x}/{y}.png', {
  attribution: "<a href="http://maps.gsi.go.jp/development/ichiran.html" target="_blank">;地理院タイル</a>"
}).addTo(map);
map.setView([35.3622222, 138.7313889], 5);
1行目(L.map)はLeafletでの地図を書込する際のおまじないです。
2行目(L.tileLayer)は国土地理院の地図タイルを使用する際に指定するURLを記載しています。
3行目(attribution 〜 </a>"まで)は国土地理院サイト内の情報を使用する際の許諾権を表示する関係でリンクを埋め込んでいます。
4行目(}).addTo(map);)は3行目で指定した内容を地図に追加するという意味です。
逆にいうと4行で閉じるまではここにタイルレイヤとして登録したい情報を追加可能ということになります。
5行目(map.setView)で東京を中心とし、ズームレベル5で表示させるという意味です。
このソースではheadのscriptでLeafletのJavaScriptライブラリをインターネットで読込する設定のため、自分のサイトには<div id="map"></div>があれば、そこの場所に地図を貼付け出来るというわけです(正確にはmapのスタイルシート設定が必要ですが)。
どうです?ちょっと勉強してみようと思いませんか?次回からは少しづつ機能を追加する方法を記載していきます。

2015年11月21日土曜日

Xposedのモジュールが衝突した場合の対応

rootを取る人にとって必要性が高い理由としてはXposedフレームワークを使いたいというのがあると思います。
私も合計13本のアプリをインストール+有効化しています。
  • 3c Toolbox Pro
  • Amplify
  • AndroPlusMod
  • *BubbleUPnP
  • *Force Touch Detector
  • Greenify
  • HandleExternelStorage
  • MinMinGuard
  • Native Clipboard
  • Statusbar download progress
  • SystemUI Patcher
  • *UnrestrictedGetTasks
  • Xperia  Xposed(LP)
  • *YouTube AdAway
*付のは正直あまり使っていない、もしくは機能がよく分かっていないもの。端末の健康を考えて近々整理したいと思います。
で、今回のネタは以前はGravity Boxを使用してタスクバーのアイコン表示を隠していたのですが、最近端末のメモリ消費量を考えてNovaLauncher と LMTの併用をやめてXperiaランチャーをメインにした結果、代わりに入れたSerajr Xperia Xposedとの衝突で画面が真っ暗になったのをこの方法で解決したって話です。
この方法、XposedモジュールとPlayアプリが衝突してブートループを起こした場合も有効です。

基本的操作方法

ここに書いてある方法でXposedを起動時に無効化します、おわり。では「英語なんかわからん」って場合は積んでしまいますので説明します。
/data/data/de.robv.android.xposed.installer/conf に"disabled"という名前のファイルを作成します。
コマンドで言うとtouch disabledになります。

解決方法1

Gravity BoxとXperia Xposedが衝突した場合、画面は真っ暗なのですが何故か電源ボタンの長押しでの電源断ウィンドウは表示されたので、PCに接続しadb shellで以下のコマンドを入力します。
su
cd /data/data/de.robv.android.xposed.installer/conf
touch disabled

解決方法2

XZDRなどリカバリをインストールしている際はリブートしリカバリを起動してリカバリプログラムのシェルから同じ操作をします。
リカバリがTWRPの場合は Advanced > Terminal Command でシェルが開きます。直接/data/data/de.robv.android.xposed.installer/confを"select"で選択してからtouch disabledと入力します。

その後の対応

端末をブートするとXposedフレームワークが無効化されて起動します。その後、フレームワークのアプリから競合関係のモジュールを無効化して下さい。インストールしたアプリが衝突した場合は、そのアプリをアンインストールもしくは設定変更して下さい。
もちろんdisabledファイルを消さないとその後もXposedフレームワークは有効化しないのでお忘れなく。

おまけ

上記とほぼ同じことを行う目的で、Xposed uninstallerのzipファイルでフレームワークを消した(リカバリで実施)場合、消す事自体は可能ですがその後の再インストールに失敗して起動しなくなった場合がありました(再度FTFイメージの焼き直しが必要)。という訳で上記の方法をまず試すことをお勧めします。

2015年11月9日月曜日

Facebookアプリのメモリ消費量対策

iOS界隈でも話題になっておりますが、オリジナルのFacebookアプリはあまりに出来が悪いので正直困ったものです。
アプリ自体も40MB以上のサイズがあり、これをほぼ毎週アップデートさせる。
さらに、ART(Android Ver.5以降)環境ではおおよそメモリを200MB以上も消費しながら常駐する(書込を適時受信する以上常駐するのは分かるにしても機能から考えると正直大きすぎだと思います)。
更に腹立たしいのはチャットの機能をMessengerに外出ししたこと。その行為自体は理解は出来ますが、このアプリ自体も非常にバカでかい。本体ほどではないけれどもサイズも20MB超えと最適化って何?というレベル。
私もいい加減嫌になって先月アンインストールし1週間位はChrome版を使用していたのですが、実は新興国向けに純正でLiteなるアプリを作っていたことがわかり、今回紹介するものです。

お断り

以上の相違・問題点があるので納得した方以外は使わないで下さい。

  • Liteは残念ながらFacebook純正アプリですが、日本ではPlayストア経由での標準インストールは出来ません。以下に書く方法で「自分の責任」で使用する必要があります。
  • 新興国向けのLightなアプリである以上、投稿にある動画をそのまま再生する機能などが省かれています。また私も全部の機能は使っていないので不明ですが今まで使っていた機能が省かれている場合があります。
  • 残念ながら、表示されているフォントが中文フォントです。日本語は見ることは出来ますが中国人特有の明朝とゴシックの入り混じった形で表示されます。さらに句読点の位置が中文フォントの書式にのっとって中心になります。

ダウンロード・インストール方法

"Facebook Lite ダウンロード"とググってAPKファイルを置いてある場所を探して下さい。ちなみに私はAPKMirrorからダウンロードしました。これを書いた時点(2015年11月8日)で1.14.0.98.222が最新版のようです。
なお、自分の端末にファイルをダウンロードしてインストールする際は、以下の2つを設定することをお勧めします(ただしセキュリティホールになりうる設定もあるので注意すること)。
  • 署名されたAPK以外は設定→セキュリティ→提供元不明のアプリを有効化して下さい。このAPKがFacebookにより署名されている場合はこの設定は不要かもしれませんが、それ以外のものはこれを有効化しないとインストールできません(申し訳ありませんが、自分は理解して常時この設定を有効化しているためLiteがこの設定が必要かは検証していません)。
  • 上記の方法で野良アプリをインストール可能にしたので、念の為ウィルススキャナアプリをインストールしておきます。無償提供される所ではAvast!やAVGあたりでもよろしいのではないでしょうか?

使用後の感想

使用後の感想はおおよそ70MBとぐっと使用メモリ量は減っています。やっぱり専用アプリ使いたい人はこっち使う価値はあると思います。ただし少しでも無駄なメモリは使って欲しくないし、逐次更新は不要な場合はChrome使ったほうがいいかもしれませんね。

2015年10月25日日曜日

init.dの使い方(Xperia Z3で確認)

初めに

init.dスクリプトは起動時にデーモンなどを起動させるものです(UNIX系のOSを使用中ならご存知でしょうが)。
Androidの場合はユーザがprocなどでカーネルパラメータを指定した場合や追加モジュールを読込させる目的で使用している場合があるかと思います。
私の現在のメイン環境では起動時にsuperSUは動作しているためrootは普通に使えるのですが、rootkitではinit.dスクリプトサポートがないためせっかく作ったカーネルモジュールを読込出来ない状況でした。
OS周りのカスタマイズにはKernelAdiutorを使用していますが、これのinit.dサポートが/system/etc/init.dにスクリプトを置いても動作していないようなのでちょっと調べてみた結果を備忘録でまとめます。

その0(どちらの方法でも共通事項)

以下の記述+最下行に何も入れない行を1行追加して下さい。
/system/xbin/run-parts /system/etc/init.d 
/system/etc/init.dディレクトリのパーミッションは755もしくは777にし、init.dディレクトリ内部のシェルスクリプトもパーミッションを755もしくは777にします(755で十分動く筈なのですが、Xdaあたりを見ると777の記述も結構あるため)。
ちなみにこのrun-partsコマンド、busyboxのシンボリックリンクです。ということは当然busyboxがインストールされていないと動作しません。

その1(私の環境では動かない)

/system/etc/init.qcom.post_boot.shに記述を追加しました。
init.qcom.post_boot.shはブート中に動作するスクリプトのなのでこれで動きそうだと思ったのですが、何故か認識できず...

その2(SuperSUと同じ方法)

そう言えばSuperSUは現状では起動時にスクリプトを読み込ませる方法で対応していることを思い出し調べてみました。
/system/etc/install-recovery.shの最下行にその1と同じ内容を記載しました。
結果としてはこれが唯一動作した形になっています。
という訳で今回はかるーく流してみました。

おまけ(自分で作ったモジュールを起動時に全て読み込む)

/system/lib/modules配下にカーネルバージョンと同じフォルダを作り、その中に作成したカーネルモジュールを配置した場合にスクリプトで全てロードさせるスクリプトです。

#!/system/bin/sh
# script to load extra modules in /system/lib/modules
KVER=`/system/xbin/uname -r`
/system/bin/insmod /system/lib/modules/$KVER/symsearch.ko
for i in $(ls /system/lib/modules/$KVER);
do
/system/bin/insmod /system/lib/modules/$KVER/$i
done
上の例、簡単に説明しますが行頭の#はコメントを示します。また1行目の#!はこのスクリプトを動作させるためのシェルプログラムを指定します。
symsearch.koを先にinsmodしているのはこれに依存するモジュールがあるからです。
私がinit.dスクリプトを記載する際、おそらくPATHが/system/binには通っておりますが、/system/xbinも含めて実行コマンドはフルパスで記述しています(無用な動作不良を防止するため)。

2015年9月11日金曜日

Chromecastを購入してみた

リビングのAV機器からPS3を片付けたせいでビデオ・写真・音楽を楽しむ手段が無くなったため小型のPCでも置こうかなぁと思っていました。
先日コストコに行った所、店頭でChromecastが並んでいて1個3,980円とちょっとだけ安くなっていたので購入しました。

セットアップについて

帰宅後、MHL向けに常時接続状態のACアダプタ経由でAVアンプに接続しても、何故か画面が表示されない。

という訳でもう一度取説を見て内蔵のACアダプタ+TV直接接続した所、無事にセットアップ画面は表示されました。

  1. ACアダプタのMicroUSB側をChromecastに刺す
  2. ChromecastのHDMIポートをTVに刺す
  3. ACアダプタをコンセントに接続
  4. TVの入力をHDMIに切替

あとはスマホにアプリを入れてペアリングするだけ。ペアリング後はAVアンプに接続変更してもちゃんと画面が表示されました。
我が家ではWiFiのアクセスポイントは5GHzと2.4GHzで2つのSSIDを利用できるため、Chromecast側は2.4GHz専用とし、それ以外の機器はメインで5GHzを使用するなどの動作は可能です。

使用感について

正直使った感想としてはプラットフォームとしては現状ではよく考えてあるけど、対応アプリ側の出来がまだまだ甘いという印象。何がそう感じさせるかというと、対応アプリが用意するChromecastブラウザ向けのHTML・CSSを使いこなして美しい画面を提供出来ているのはGoogle謹製のYoutube等しか自分の手元では無いように見えます。

それに何といっても自分にとって最大の問題はChromecast経由で音楽を聞いた場合、どのアプリもギャップレス再生ができないこと。ライブアルバムやノンストップリミックスアルバムのように途中でブツ切れすると興醒めするのでこれはなんとかして欲しいです。

補足

9/22時点でちょっとわかったので補足します
今現在でギャップレス再生に対応する方法は以下の2つのようです。

  1. Playミュージックアプリをインストールし、ストア経由でネットワークストリームとして再生させChromeCastにキャストした場合。
  2. BubbleUPnPを起動し、ChromeCastに接続させAUDIOCAST機能を有効にした状態で他のプレーヤ(当然ギャップレス再生対応のもの)で楽曲再生した場合。


1.については正直このサービスを利用しないと動作の検証はできません。それに月額798円払うのはどうかなぁという印象(ちょっと高いかなぁと)。
(Playミュージック自体には自分の端末に複写した楽曲をキャストする機能はありませんので動作は確認出来ず...)
2.についてはたしかにこの方法で動作するんだが、端末のCPU負荷(=バッテリ消費)が激しいし、再エンコードの際に生じるラグがあるため制御が数秒程もたつく...

SDKをちょっとだけググった結果ではどうやらスマホ側で音声・映像データをデコードしてそのままストリーム再生出来るようなのですが、それを行っているような賢いアプリは今の所見つからない。これを書いている時点でトラック間のラグが最も小さいのはClockWorkModが作成するAllCastでした。ただしAllCastは自分のメイン環境だと何故か楽曲を再生しようとした瞬間異常終了してしまう(メディアサーバ経由の場合。ファイルとして再生アプリを選択した場合は再生可能だが、この時はアルバムアート等が表示されない)。非常に悩ましいですね。
という訳でアプリ側でデコードし、映像・音声ストリームする(ノンストップで)アプリ無いんでしょうかね?

あともう一つ謎なのはこの映像・音声ストリーム配信のビットレートとChromecast自体が対応するビデオ解像度・音声出力周波数とビット数がよくわからないことです。その辺りはSDKでも見て今度はちょっと調べてみたいと思います。

おまけ(Androidでの音楽再生アプリについて)

今自分の手元では音楽再生用アプリがいくつもインストールされている状況です。
結局メインで使っているPowerampは未だChromecast未対応。
Chromecast対応するアプリだけでもSONY謹製のMusic、BubbleUPnP、Rocket Player、Shuttle、AllCastと使ってみたのですがこれだけと絞ることが出来ない状況...
Chromecast非対応もNoozy、UBIO、HF Playerと未だに入っている。そのうち整理したいと思います...

2015年9月6日日曜日

2010年冬モデルのNEC製VALUESTAR N(VN770WG6B)でメモリを8GBに増設し、Windows10(64bit版)化する


自分のではないのですが、連れのPCはNECのVALUESTAR Nの2010年冬モデル(VN770WG6B)です。
このモデル、Windows7の32bit版がプリインされており、メモリも4GB(最大4GB)しかなく通常動作でメモリ不足による不調を訴えていました。
当初はそのまま使い続けるつもりでしたが、最近使っていなかった地デジチューナのB-CASスロットがいつの間にかカード読取不調になったこと、CPUやチップセットから本来は64bit版で動作可能である疑いを持った矢先、試しに自分のLenovo G570に刺さっていたメモリをこの本体に挿した所あっさりと8GBで認識したことからWindows10(64bit版)にアップグレードしましたので今回紹介します。

まず今回の改造では以下のリスクがありますので予め説明しておきます。

その1)TV放送のPC経由での視聴について

Windows10では現状地デジ・BS他をPCで見られなくなります。
このPC、Windows Media Centerを経由したSmartVisionというソフト経由で地デジを試聴出来ていましたが、Windows Media CenterがWindows 10で消されるため、当然ながら動作できません(将来何らかのソフトウェアで対応する可能性はあるかもしれませんが...)

その2)サポートについて

4GB以上のメモリによる動作はNECのサポートを受けられません。
NECのWebサイトにも最大4GBとしか情報がないですし、バッファロー他の周辺機器のサイトにもこの機種について増設時に認識したという情報はありません。
現状動作しているWindows10機にCPU-Zをインストールしてメモリ関連の情報を表示したところ、DRAM Freqが531MHzと表示されていることから、DDR3-1066(CL=7、7-7-7-20)対応のメモリでないと動作しないようです。


その3)Windows10の出来について

Windows10はこれを記載の時点では正直公開ベータと言える出来です。
後述しますが、この本体の場合はBIOS画面経由でないとWiFiのON/OFFや本体電源OFF時のUSBポートでの給電制御を切替出来ませんでした(このVALUESTARにはWindows7で動作する切替アプリがあるのですが、Windows10では動作しなかった)。
このようにハードウェアが特殊なPCでは現状Windows10 64bit版が動くとは思えません。

あと、私が経験した失敗としてはPCのバックアップを取らずにWindows7→Windows10へアップグレードした所、アップデート最後のユーザプロファイル作成で再起動を繰り返しデスクトップが開かないという不具合が発生しました。
結局はWindowsPEのCD-ROMイメージを作ってこれでUSB HDDにデータをサルベージ出来たので無事に済みましたが、そういう意味も含めて、Windows 10は現時点では公開ベータだと思いますので現状の環境を維持したい方にはお勧めしません。

やり方


それでは今回実施した方法について説明します。

1)メモリを増設する

純正で接続された4GBのメモリを外し、4GB×2=8GBに増設します。
 このPCの場合、DDR3-1066(CL=7、7-7-7-20)対応でないと動作しないと思います。
 BIOSで8GBと表示されることと、バッファローなどのRAMディスクアプリをインストール済みの場合はWindows7の管理アプリで8GBと認識されることを確認して下さい。

2)Windows10のインストールイメージをダウンロードする

そのままだと予約したとしてもおそらく何時までたってもアップグレード案内は届かないと思いますので、その場合はMicrosoftのサイトから直接ダウンロードするしかありません。

 ちなみにダウンロードするイメージについては32bit/64bit両方入っているものが最適でしょう。メモリを増やすつもりがなければ32bit版で使い続ける(それも購入時点の全機能を使うならそのままWindows7で)と良いですが、メモリを増やした状態で使うなら64bit版が最適です。

 64bit化するには一旦32bit版でアップグレード後64bit化する必要があるため、32bit版と両方必要になります。

3)Windows7向けの64bit版ドライバセットをメーカサイトからダウンロードする。

このドライバセット、普通に121ware.comから検索しても見つかりません。このPCの型番で"VN770WG6B 64bit driver"をgoogleで検索しないと表示されません。

 正直、どうしてもインストールしていれないとならないドライバはSDカードスロットぐらいなもので、これ以外は不明なデバイス表示を消す目的しか無いので(無線キーボードのHOTボタン機能やTVチューナ以外は標準で認識されるドライバで正常動作する)、ここは割りきってしなくてもいい処理かもしれません。

4)Windows10のインストールイメージからシステムをアップグレード

念の為アップグレード時の診断でハネられたソフトウェアをアンインストールするだけではなく、それ以外に怪しいソフトは全部消すべきだと思います。
 私の場合はバッファローのRAMディスクドライバを使用していたため、これがアップグレード失敗の原因だったと想定されます。

 なお、Windows7からアップグレードした場合は、もともと動作していたbit数と同じものがインストールされます。
 このPCの場合は32bit版になります
(これが一番NECさんに文句が言いたいところです。この機種販売時点でNECが判断した時は32bit版が最良の選択だったんでしょうが、同時期の他社のように何故32と64bit版の両方用意してユーザで最初期使用前に選択させてくれなかったのか。本当に疑問です。)

5)Windows10が無事立ち上がったら、デバイスの動作チェック

アップグレード後デスクトップが表示されれば多分大丈夫だと思いますが、一番怪しいところとしてWiFiのデバイスドライバがインストールされても接続出来ないというのがあります。
 この場合は一旦本体の電源を再起動してBIOS画面を立ち上げ、WiFiの機能をEnableにしてWindows10を立ち上げてみて下さい。

 TVチューナなど標準ドライバで認識されないデバイスは32bit版のドライバがPC内に保存されているのであればそれをインストールして認識するか確認してみてもよいでしょう(ただしこの後で64bit化するのであればしなくても良い)。

6)64bit版のWindows10をクリーンインストール

せっかく8GBで使用するのでしたら、32bitでは残念ながら広大なRAMディスクとしてしか使えない3.2GB以降のメインメモリを有効活用可能な64bit版にしてしまいましょう。

 64bit化するには再度インストールメディアを使って64bit版をクリーンインストールして下さい。ちなみにディスクを完全消去しない限りは前のWindowsフォルダはWindows.old名で残っています。

 普通クリーンインストールする際は新しいライセンスが必要になりますが、Windows7→10化した時点の(32bit版での)ライセンス認証が残っているため、64bitをクリーンインストールしても認証違反とは表示されません (このやり方での無料での32bit→64bit化は今後もずっと使えるかどうかはわかりません。念のため)。

 また、このWindows10でのライセンス認証状態は現状構成でのハードウェアで適用可能なため、HDD・メモリ・その他本体スロットの拡張ボード類の変更を行った時点で切れる可能性があります。

7)64bit版起動後、標準でサポートされないデバイスのドライバをインストール

このPCで標準ドライバで使えないデバイスはSDカードスロット・地デジTVチューナ・キーボードのHOTキーの3つだけだと思います。

 SDカード・地デジチューナ共に先にダウンロードしたWindows7の64bit版ドライバがあるのでそれをインストールすればデバイスとしては認識すると思います(ちなみに先程手元のSDカードを挿したらスロットは正常に動作しました)。
 キーボードのHOTキーは使えなくても問題ないと判断し、ドライバは探していません。

まとめ

Windows10を使って正直な感想としては、公開ベータだなぁというところですか(出来が良い悪いはともかく、ポリシーが無いのと、OSのソフトウェアアップデートが有無を言わさず自動で行われるのが問題)。コントロールパネルの表示があちこちWindows7の踏襲とWindow8以降のものが混在していたり(同じ設定なのに)、正直不思議なOSです。
 ただ、動かないソフトウェアはある(メーカの動作保証が必要なハードウェア直結関連のもの)のですが、普通のソフトウェアでの動作不具合は今の所あまり遭遇していません。

 現状使っているPCの全機能を失いたくない人、メーカの動作保障が気になる人、互換性の問題により古いソフトが動かなくなるのは嫌な人はメーカから出荷されたWindows7の状態で使い続けるほうがいいと思います。
 でも、現状メモリ不足等で動作が重く何とかしたい(新しいPCなんか買う金はないけど実験はしてみたい)人はお試しする価値はあると思います。
 正直我が家ではWindows10(64bit)化した結果、PCの動作が軽くなりまだ数年はこの本体使い続けられるのではという評価をしております。

 なお、リカバリ用のDVD・BDを作成した人は一度Window10をインストールしても元に戻ることは可能だと思います。ただしデータの復元という面倒臭い作業は残りますが。
 (リカバリメディアなしでも元に戻すことは可能らしいですが、私の遭遇したようなデスクトップが表示されない自体では元に戻すことは出来ませんでした)。

おまけ、ReadyBoostについて

Windows7では8GBのUSBメモリでReadyBoostを使用していました(32bit版のため、4GBしか領域が作られていなかったが)。
 同じUSBメモリWindow10でもReadyBoostとして使いたいと思いましたが、そのままではサポート外のデバイスと表示され弾かれました。USBメモリの全領域をexFATでフォーマットしなおしたところ、RadyBoost対応メモリとして認識出来ました。