2015年12月のCM12.1リリース

2015年12月のCM12.1リリース

16:50 0
12月分のCM12.1と、日本語訳を取り込んだCM13.0を更新しました。

Euphoria-OSとResurrection-Remixについては、先月以降更新がなくなってしまったので、尻切れですが先月分が最終ビルドになります。

BlissPopは多少更新がありましたが、ビルドしている暇がなかったので、新年に持ち越しです。

私がCyanogenModを好んで選ぶ理由の一つがサポートの信頼感ですね。コミュニティやメンテナがはっきりしないROMは開発者の気分でディスコンになりやすいので、老舗の安定感は安心できます。

更新履歴は各サポートページから確認下さい。

2015年12月のCM13.0リリース

23:08 3

クリスマスには少し遅くなりましたが、CM13.0の12月分を更新しました。

さすがにTXのストックカーネル(とストックバイナリ)も時代遅れになって、Android6.0で加わった変更に追随するのが大変になってきました。Android側のソースにも色々と手を加えてWi-Fiと内蔵ストレージ、SDカードを有効化したので、だいぶ常用できるようになったと思います。

残った不具合はカメラとFMですが、カメラはまだしばらく時間がかかりそうです。少なくともXperiaのCMメンテナが苦戦しているうちは難しいでしょう。FMはCM13.0の開発が進めば自ずと使えるようになると思います。

年末までには、CM12.1をはじめ他のROMもビルドして公開します。

詳しい更新履歴はCM13.0のサポートページで確認してください。

ブートローダーがロックされた端末向けのカスタムROMのビルド方法解説

16:55 9

先日よりコメント欄で、ブートローダーがロックされた端末向けのカスタムROMの作り方についてやり取りをしていたのですが、出来上がったノウハウを共有して広めるのも良いかなと思い、ビルド手順を分かりやすく解説することにしました。


おおまかな流れ

  1. ビルドしたいROMのソースを取得
  2. ビルドしたいROM向けのデバイスツリーを用意
  3. ビルド対象の端末のストックカーネルソースを取得
  4. ビルドしたいROMのソースツリーにストックカーネルソースを適切に配置
  5. デバイスツリーを編集してストックカーネルソースとdefconfigを使うようにする
  6. デバイスツリーを編集してストックカーネルが対応しない機能を削るために、フラグを追加、削除
  7. ストックカーネルを使う際に問題が起こるdisplay HAL、media HALあたりを編集
  8. その他、ストックカーネル向けに変更した方が良い部分を適宜修正(特にSELinuxの動作モードについてはsepolicyなりinitなりを編集してpermissiveかdisabledにする)
  9. ビルドが成功するまで、何度もトライアンドエラーでエラー箇所を修正
  10. ビルドが成功したら、出来上がったROMとramdiskを取り出す
  11. hijack-ramdisk内のシェルスクリプトを対象端末向けに調整して、出来上がったramdiskも中に入れる
  12. 出来上がったROMとhijack-ramdiskを実機に導入して、機能的なバグがあればデバイスツリーを修正して再ビルド

実践

上記の流れに沿って実際にブートローダーがロックされた端末向けに作業してみます。
例としてhayabusa(GX)を使っても良いのですが、せっかく一から書き起こすので新規にhuashan(SP)向けにCM12.1をビルドしてみます。

*ここでは標準的なROMのビルド環境は全て整っている前提で話を進めます

1. CM12.1のソースを用意

repo init -u https://github.com/CyanogenMod/android.git -b cm-12.1

repo sync -j16

2. huashanのデバイスツリーを用意

. build/envsetup.sh

breakfast huashan

huashanのデバイスツリーとCMのカーネルソースがダウンロードされます。

デバイスツリーを用意したら、実機をつないでプロプライエタリなファイルを取り出すのですが、ここでは便宜上、TheMuppetsから拝借します。

svn checkout https://github.com/TheMuppets/proprietary_vendor_sony/trunk/huashan

ワーキングディレクトリにベンダーファイルを含んだ"huashan"というフォルダが作られます。

3. huashanのストックカーネルソースを入手

huashanのストックカーネルソースをSony Developer World の Xperia open source archivesで手に入れます。

huashanの最終ビルドは12.1.A.1.207なので、それ用を使いましょう。

ソースは圧縮されているので適当なアーカイバで解凍して、中のkernelフォルダを取り出します。
"kernel"では分かりにくいので、仮に"viskan"と名前を変更します。
(huashanのプラットフォームはviskanというそうです。blueとGPU以外同じSoCで互換性も高いのにわざわざ分けられているのですね。)

4. デバイスツリー、ベンダーファイル、カーネルソースを配置

ストックカーネルソースとベンダーファイルを用意したら、CMのソースツリーが以下の形になるように配置して下さい。

CM12.1-huashan
├── abi
├── android
├── art
├── bionic
├── bootable
├── build
├── cts
├── dalvik
├── developers
├── development
├── device
├── docs
├── external
├── frameworks
├── hardware
├── libcore
├── libnativehelper
├── ndk
├── packages
├── pdk
├── prebuilts
├── sdk
├── system
├── tools
├── kernel
│   └── sony
│       ├── msm8960t
│       └── viskan
├── vendor
│   ├── cm
│   ├── cmsdk
│   └── sony
│       └── huashan
└── Makefile

5. デバイスツリーをストックカーネル向けに編集

ここからは、huashanのデバイスツリーをストックカーネル向けに編集します。

使用するカーネルソースとdefconfigの場所を変更します。

device/sony/huashan/BoardConfig.mk

# Kernel properties
TARGET_KERNEL_SOURCE := kernel/sony/viskan
TARGET_KERNEL_CONFIG := viskan_huashan_defconfig

メディア、ディスプレイ、オーディオHALはcaf版を使うので、そちらも追記

device/sony/huashan/BoardConfig.mk

# QCOM/CAF hardware
COMMON_GLOBAL_CFLAGS += -DQCOM_HARDWARE
BOARD_USES_QCOM_HARDWARE := true
TARGET_QCOM_AUDIO_VARIANT := caf
TARGET_QCOM_DISPLAY_VARIANT := caf
TARGET_QCOM_MEDIA_VARIANT := caf

# QCOM enhanced A/V
TARGET_ENABLE_QC_AV_ENHANCEMENTS := true

同時にDisplay HALの不要なフラグを削除かコメントアウト

# Display HAL
USE_OPENGL_RENDERER := true
TARGET_USES_ION := true
TARGET_USES_C2D_COMPOSITION := true

#TARGET_DISPLAY_USE_RETIRE_FENCE := true
NUM_FRAMEBUFFER_SURFACE_BUFFERS := 3

6. ストックカーネルに合わせてmedia-cafとdisplay-cafを入れ替える

本来は個別にビルド時のエラー箇所を修正する必要がありますが、今回は関連箇所のコミットをリバート済みのリポジトリを使わせてもらいます。


hardware/qcom/display-caf/msm8960
hardware/qcom/media-caf/msm8960

二箇所のフォルダを入れ替える

7. その他、ストックカーネル向けの変更

huashanのストックカーネルソースはGCC4.7でビルドされていますが、CM12.1はGCC4.9でビルドされるので、それ用の変更をカーネスソースに加えます。

kernel/drivers/usb/gadget/Makefile
kernel/net/bluetooth/Makefile

KBUILD_CFLAGS += -Wno-sizeof-pointer-memaccess

Android 5.1のSELinuxの制限を緩めるために、sepolicyを編集

external/sepolicy/Android.mk

FORCE_PERMISSIVE_TO_UNCONFINED:=false

このままビルドするとzip内のカーネルが自ビルドのものになるので、適宜ストックカーネルと入れ替えるようにする。(詳しくは、そのうち今回のソースを公開するので、そちらを見てください)

8. ビルド開始

さて、これで準備が出来ました。いよいよビルドを始めます。

brunch huashan

全てが適切に編集されていればビルドが通るはずです。

まとめ

今回作成したブートローダーがロックされたXperia SP用のCM12.1のROMとSP向けのhijack-ramdiskを公開します。ただ、実機で動作確認できないので、起動しないかも知れません。

cm-12.1-20151204-UNOFFICIAL-huashan

huashan hijack-ramdisk for CM12.1

Xperia SPを持っていて試される方がいれば、結果を教えてください。

流れとしては以上のようになりますが、見れば分かるとおり、それなりに処理の内容を理解してエラーに対処できる程度の知識がないと難しいです。ただリポジトリを引っ張ってきてビルドするレベルからのステップアップには良いかと思います。

非rootでマルチユーザーを有効化する方法(失敗)

22:41 2

非rootでマルチユーザーを有効化する方法(失敗)

最近は枯れた端末の開発がメインになって新しい機種の事情に疎くなりがちなのですが、docomo版Xperia Z5シリーズを除いて、Xperiaの国内キャリアモデルはマルチユーザー機能が塞がれていると聞きます。

そもそも自分がマルチユーザー機能を使ったことがないので全く興味が無かったのですが、同じ端末上でソシャゲの複アカ運用で使うという話を聞いたときはなるほどな、と思いましたね。

マルチユーザーを有効化する手順は割とあちこちのブログでまとめられていて目新しさはありませんが、どこも大体root化が必要であると書いています。

# Multi Users
fw.max_users=3
fw.show_multiuserui=1

こんな具合にbuild.propに追記する方法ですね。

しかし、Androidのシステムプロパティを設定する方法はbuild.propの編集に限りません。
同じ事をadb shellから行うとどうなるか試してみました。

実践

私のZ3 Compactはroot化してあるので本当に非rootで同じ事ができるのか自信はありませんが、SuperSUからrootを無効化して行いました。


端末とPCをつないでコマンドプロンプトから以下を打ち込みます。

adb shell
setprop fw.max_users 3
setprop fw.show_multiuserui true

すると、ちゃんと端末の方でもマルチユーザーの設定が見えるようになりました。


解説

おそらく、shell権限で実行しているのでコマンドが通るのでしょう。同じ事を端末上のアプリからしても拒否されます。

ただ、setpropで設定する値は一時的なものなので、build.propと違って端末を再起動する度にPCから同じ操作をして設定を再表示する必要があります。もっとも、最近では再起動の頻度も減っていますから、何も出来ないよりかはマシというところですね。

今後の展望

上記と同じコマンドを発行するアプリを作って手軽に扱えるようにしようと思ったのですが、アプリの権限ではコマンドが拒否されてしまったので使い物になりませんでした。
脆弱性になるのでまず無理でしょうが、アプリにシェル権限を持たせることができれば、ずっと面白くなるのになと思います。

今後はどんどんセキュリティが厳しくなって、リテールデバイスをユーザーがカスタマイズする余地が狭まってくるでしょうから、こういった非rootでもシステムの一端に触れられるような小技を探していきたいなと思います。

非rootユーザーの方で試される方がいれば、結果を是非教えてください。

訂正

これでいけるだろうと高を括っていたのですが、コメントで報告頂いたところによると上手くいかないようですね。もしかすると、自分でも覚えていないうちにroot権限でsetpropをしていて、その形跡が残っていたのかも知れません。やはりそう易々とは遊ばせてくれないようですね。
報告頂いた方、ありがとうございました。

2015年11月のROMリリース

2015年11月のROMリリース

22:43 0
11月のROMリリースです。

CM12.1、Resurrection-Remix5.5.9、BlissPop4.0.3、Euphoria-OS1.1を11/22付のソースでビルドしました。主な変更はBlissPopに各種最適化オプションを付けた点と、RRをPermissiveに変更した点です。

CM13.0についてはいくらかのバグを修正しましたが、常用までもう少しかかりそうです。

それぞれのROMの更新履歴は、各サポートページを確認ください。
Xperia GXの/dataをSDCardパーティションへマウントする

Xperia GXの/dataをSDCardパーティションへマウントする

23:30 0
前回のエントリで、GXには古い端末ならではの悩みがあると書きました。データ領域と内蔵ストレージの領域が別のパーティションに分かれているために、データ領域に2GBしか振り分けられずAndroid 5.0以降ではすぐに空き容量低下となってしまう問題です。

解決案

システムのパーティションをマウントするための指定は、ramdisk内のfstabで行うのですが、この記述を書き換えることで/dataをUserdataではなく、SDCardへマウントしてしまうという考えです。

こうすることで、2GBしか割り振られていないUserdataではなく、11.1GBのスペースがあるSDCardパーティションを使って、その中に内蔵ストレージ領域をエミュレートさせる(=/data/mediaを作る)ことが出来るのではないかと思います。

/dev/block/platform/msm_sdcc.1/by-name/SDCard     /data             ext4        noatime,nosuid,nodev,barrier=1,data=ordered,noauto_da_alloc                               wait,check,encryptable=footer,length=-16384

もともとのUserdataパーティションは、適当な名前でマウントして、/data内の手頃なフォルダからシンボリックリンクを張るなどすれば無駄がないでしょうね。

これならば、/dataの逼迫問題とAndroid 6.0以降のVoldの変更にいっぺんに対応できるはずなので、良案と思っているのですが、実際に試すとなるとファイルのバックアップやらフォーマットが面倒ですね。簡単にCM12.1以前に戻れなくなってしまいますし。

<参考>
鈴の音情報局blog CM12.1(Android 5.1.1)を焼いたXperia GXをしばらく使ってみて・・・思いの外快適、しかし・・・

Androidのストレージ領域の取り扱いについて(Adoptable Storageとは)

23:00 2

私がAndroidの中身について触りだしたのが2012年後期モデルのXperia GXからですが、Androidのストレージ領域の扱いについて当時のモデルから今に至るまで何度か設計に変更がありました。

内蔵ストレージ

GXの頃は、内蔵ストレージ(=ユーザーが動画や音楽などを置いておく16GBやら32GBの場所=/sdcard)は、一つのeMMCチップ上で15番目のパーティションとして用意されていました。GXのパーティション構成は以下のようになっています。

Number  Start (sector)    End (sector)  Size       Code  Name

   1             256            4351   2.0 MiB     FFFF  TA

   2            4352            7423   1.5 MiB     FFFF  Boot

   3            7424           10495   1.5 MiB     FFFF  Boot2

   4           12288           53247   20.0 MiB    FFFF  Kernel

   5           53248           55295   1024.0 KiB  FFFF  TZ

   6           57344           63487   3.0 MiB     FFFF  modemst1

   7           65536           71679   3.0 MiB     FFFF  modemst2

   8           73728           79871   3.0 MiB     FFFF  fsg

   9           79872           90111   5.0 MiB     8300  ramdump

  10           90112          106495   8.0 MiB     8300  apps_log

  11          106496          139263   16.0 MiB    8300  FOTAKernel

  12          139264         2654207   1.2 GiB     8300  System

  13         2654208         3166207   250.0 MiB   8300  Cache

  14         3166208         7360511   2.0 GiB     8300  Userdata

  15         7360512        30535646   11.1 GiB    FFFF  SDCard


15番目の11.1GBでSDCardというラベルが貼ってあるものがそれですね。内蔵ストレージなのにSDカードというラベルもおかしな話ですが、初期のAndroidは内蔵ストレージ領域を持たず、外部SDカードにしか対応していなかった頃の名残です。その一つ前のUserdataが/dataとしてユーザーアプリなどの保存場所に使われるのですが、このパーティションは2GBしか割り振られていないので、Android 4.1.2の時代ならまだしも、Android 6.0のご時世でARTのoatファイルがスペースを取るようになると、すぐに空き容量が無くなります。

そういった問題を解決するためか、同じblueプラットフォームでも2013年前期に発売されたXperia SPあたりから、内蔵ストレージ用に専用のパーティションを用意することはなくなりました。
具体的には、上の表でいうところのUserdataとSDCardが統合されて、10GB以上の/data領域を確保できるようになったわけです。そして、今まで内蔵ストレージとして用意された領域(/sdcard)は、/data/media以下で扱われるようになりました。flashtoolでWipe Dataすると、内蔵ストレージも消えるのはこのためです。

言い換えると、ユーザーアプリをインストールする場所と音楽などのメディアを保存する場所が、同じ領域を共有するようになったわけですね。

ストレージの扱い

ストレージの扱いについては、かなり混迷を極めたといって良いでしょう。内蔵ストレージとSDカード用のマウントポイントも取っ散らかっていて、よくこれだけ作ったものだと思います。

/mnt/media_rw/sdcard0
/storage/sdcard0
/sdcard
/mnt/sdcard
/data/media
/storage/emulated

これらが全て同じ領域を指しているのだから面倒です。(厳密には、それぞれ役割があったり互換性のためだけにシンボリックリンクになっていたりします)

Android 6.0のAdoptable Storage

Android 6.0ではストレージのマウントを担当するVoldに大きな変更が加えられて、Adoptable Storageという概念が登場しました。

ユーザーへの利点は、外部SDカードを挿入したデバイス専用にフォーマットすることで、あたかも内蔵ストレージ(/sdcard)として利用することが出来る点です。

Xperia M4 Aquaの8GBモデルが、先の表のようなパーティション構成の結果、/data(+/data/media)領域が1.26GB程度になってしまったことでひんしゅくを買ったのは記憶に新しいですが、仮に128GBのmicroSDカードを(/data/media)としてフォーマットすれば、その分、インストールできるユーザーアプリは増えますし(/dataの使える領域が相対的に増える)、広大な領域を内蔵ストレージとして音楽などのメディアの保存に使えるわけです。

開発者への利点は、先に挙げたようなマウントポイントをすべて取り払うことができるようになったところです。Voldがダイナミックにストレージを扱うようになったので、fuseデーモンにマウントポイントを指定したり(storage_list.xml)、initプロセスで互換性のためにマウントポイントのシンボリックリンクを張る必要もなくなりました。

ただし、新しいVoldはXperia GXのような、内蔵ストレージ用にSDCardという専用のパーティションを持つようなデバイスのことは考慮していないようです。Google的にはいい加減新しい端末に乗り換えろということなのでしょう。この対応については、同じように内蔵ストレージ専用のパーティションを持つOPPO find 7用にCMのメンテナーが試行錯誤してくれています。

少々、専門的な話になったので、GXでの実用的な話は次のエントリに分けることにします。

<参考>
Adoptable Storage | Android Open Source Project

Sony cripples the ‘8GB’ Xperia M4 Aqua | Xperia Blog

Change Id7ec3ea4: vold: Support internal storage partitions | review.cyanogenmod Code Review