Dospara DG-Q10S

2013年07月購入。お値段¥19,980。

一時期は親向けにLenovo IdeapadS12を渡していたのだけれど、分からない＆やる気無いで放置だったため、タブレットならどうかと試してみた。
結果的にはこれでもダメだったのだが、これについては安易に親を責められないことがあった。
このタブレット、使っているうちにどんどん動きが悪くなり、2,3回画面に触れただけで分単位でプチフリを起こすほど酷くなる。
これじゃあ、特に初心者には何がどうなってんだかさっぱり分からないし、触れても反応しないから何回もあちこち触れているうちに数分遅れでダダダと処理されるのでどんどんおかしな状況になっていく。
その後、スマホcovia FLEAZ F4 (CP-F03a 8G)を渡して、これを引き取ったのだが、ある程度こういうデバイスには慣れているはずの筆者でも正直エッ？　って思うような動きだった。故障かと思った。使えねぇって思った。
でも、どうやらこの時期のスマホやタブレットでは割とよくある症状だったようですね。

消費電力の大半がGPUとバックライトのようで、例えば電子書籍のデータダウンロード中に画面オフになると0W表示にもなったりするのに、画面オンでは4W（まれに5W）まで跳ね上がります。画面オン（最低輝度）アイドル状態では2W表示ですね。画面サイズが大きいので妥当なところでしょうか。

プチフリ頻発の原因

筆者の想像交じりですので間違っている可能性もありますが、この現象は初期のSSDなどのメモリストレージで起こったものと同じものと思われます。
元々、NAND FLASHメモリは書き込みが異様に遅く、製品にもよるかもしれませんが、DG-Q10Sの場合は多分16KB単位で一旦全消去してから書き込みを行います。
例えば、ほんの1Byte書き換えたいだけでも、その1Byteが存在する16KBブロックを全消去して書き直すのです。
実際にはそんなことをやっていると遅くてしょうがないので、とりあえずまだ書き込んだことのない16KBブロックにいきなり書き込みに行き、元のブロックは放置して使わないという方法を取ります。（昔の話ですよ。今はもっと賢く制御しているはず）
こうすると、そこそこ速いのですが、「書き込んだことのないブロック」というものが無くなってしまったらどうなるでしょう？
消去できるところを探して消去してから書き込むことになり大幅に速度低下を起こします。
それでも、ただの書き換えならまだ良い方です。書き換えるブロックだけ考えれば済む問題ですから。

例えば、書き込むバイト数が増えてしまったら？　どうなるでしょう？
書き換えるだけでなく、収まりきらない分をどうにかしなければなりません。同じブロックに収めようとすると他のデータがはみ出します。違うブロックに書き込む？　既にそうやって対処してきたデータ達がつまみ食いのように書き込まれているかもしれませんね。
書けるところから書くという場当たり的対処をしてきたことで、僅か1Byteのデータの書き込みに16KBの領域を食いつぶしてしまっている場合もあり得ます。そうなると、既に書き込まれているデータと新たに書き込みたいデータをマージして全消去して書き込み直すといった作業が連鎖することになるのです。
これがプチフリの原因。プチフリーズと言っても、フリーズが固まったまま動き出すことがない、というのに対して、プチフリーズはそのうち動くようにはなるけど分レベルで平気で待たされるという状態になります。
こうなると、あっちを書き直したら、こっちも書き直さなきゃ、でもこっちを書き直そうとするならもう1ブロックデータ書き直さなきゃダメだ、みたいなことを延々やってるのです。

DG-Q10Sの場合、この現象に拍車を掛ける原因がもう一つあります。アプリやデータを置いておく領域が1GBしか確保されていないことです。
FLASHメモリ自体は16GB装着されているのに、わざわざ1GBという狭い領域でパーティションを区切っています。その狭い中をアプリが動作した結果データを読み書きしていますので、あっという間に未書き込みの領域が無くなります。
それ以前に、普通にアプリをインストールしていくだけでも早々に領域不足に陥りますよね。そんな状態でアプリがデータ書き換えしたくて書き換えできる領域を探して数分間の旅に出る、と。

一方で、外付けSDカードと同じような扱いになる領域は約13.55GBと、ふざけてんのか！　と言いたくなるくらい大量に確保しています。
明らかにバランスがおかしいです。というか、こんな配分、今どきのAndroid端末ではまずやりません。というか、今はシンボリックリンク置いて同じパーティション内になるようにしてますよね。

この、初期の書き込み制御が全くなっていないNAND FLASHとパーティションの切り方が壊滅的に悪いという二つの相乗効果で、DG-Q10Sは全く実用にならないAndroidタブレットに成り下がってしまったものと思われます。
そこで、

パーティションを切り直す

作業を遅まきながらやってみました。
試行錯誤しながらでしたので、すっきり綺麗にはまとまりませんが、その方法をここに記載しておこうかと思います。

■注意事項■
ROM書き換えという危険な作業を行います。この記事を真似して失敗し、文鎮化しても筆者は責任を負いません。
試行錯誤しているので、余計な回り道や、あるいは記述が不足している可能性があります。記事の意味が理解できない方は絶対に手を出さないでください。
使用しているツール等のリンクは貼っていません。場所が変わったり、無くなったりすることが比較的良くあるからです。実行したいときに検索するのがベターだと思います。

RockchipのツールとドライバでROM書き換えができますが、最新のものはうちでは動作しませんでした。うちで動作した組み合わせはWindowsXP上で「RK_DriverAssitant」のドライバを導入し、「RKBatchTool v1.7」でROM書き込みです。「RKBatchTool-v1.8」ではイメージファイルを認識できず、それに同梱のドライバではDG-Q10Sを認識できませんでした。また、Windows10上でも認識できませんでした。
ROMの中身を弄ってパーティション設定を変更する必要があります。ROMそのものをDospara提供のファームデータを解凍したものがそのまま使えます。ROMの中身を弄るためにUnpack/Repackができるツール「RK3xxx_firmware_tools_5.99.07.00」を使用しました。（ほかにも色々なツールを試しましたが、初めてまともに動いたのがこのツールでした。）
このROMを弄れるツールはWindows10で動作しました。ツールを実行して、DG-Q10S正規のupdate.imgを指定して「Extract」します。すると、実行フォルダのtempフォルダ配下にイメージが展開されて複数のファイルができています。
今回弄る必要があるファイルはtemp\Android\parameterファイルです。メモ帳等の余計なバイト列を追加しないシンプルなテキストエディタで開きます。（筆者はサクラエディタで編集しました。）
変更するのは最後の一文

CMDLINE:console=ttyFIQ0 androidboot.console=ttyFIQ0 init=/init initrd=0x62000000,0x00800000 mtdparts=rk29xxnand:0x00002000@0x00002000(misc),0x00006000@0x00004000(kernel),0x00008000@0x0000a000(boot),0x00010000@0x00012000(recovery),0x00020000@0x00022000(backup),0x00040000@0x00042000(cache),0x00200000@0x00082000(userdata),0x00002000@0x00282000(kpanic),0x00100000@0x00284000(system),-@0x00384000(user)

ここだけです。
ここの値は恐らくセクターを表していて、ここの数値の1が512バイトに該当します。
例えば、0x00200000@0x00082000(userdata)と書いてありますが、
0x00200000　＝1GB
@0x00082000　←開始位置
(userdata)　←いわゆるアプリ等が格納される領域
となります。
@の数値がその手前の数値分足し算されて次の項目の値になっていることが分かりますか？　(userdata)の次の(kpanic)の開始位置は@0x00082000に(user)の容量0x00200000が足されて@0x00282000となってますよね。（連続領域に順々に領域確保していることが分かります。）

ですので、ここの数値を書き換えれば各領域のサイズは自由自在です。
そこで筆者はこのようにしました。

CMDLINE:console=ttyFIQ0 androidboot.console=ttyFIQ0 init=/init initrd=0x62000000,0x00800000 mtdparts=rk29xxnand:0x00002000@0x00002000(misc),0x00006000@0x00004000(kernel),0x00008000@0x0000a000(boot),0x00010000@0x00012000(recovery),0x00020000@0x00022000(backup),0x00040000@0x00042000(cache),0x00E7C000@0x00082000(userdata),0x00002000@0x00EFE000(kpanic),0x00100000@0x00F00000(system),-@0x01000000(user)

(user)を0x01000000 (8GB)になるように開始位置を調整。それに合わせて(system)と(kpanic)の位置を調整。
増えた余裕分を全て(userdata)に回し、0x00200000 (1GB) → 0x00E7C000 (約7.2GB)へと増強
16進計算ですから間違えないように、それから開始位置の計算もきちんと合わせましょう。最後の(user)は開始位置から最後まで領域確保されることにになりますが、トータルで16GBのNAND FLASHですので、0x01FFFFFFを超えるようにしてはいけません。
実際には(user)が7.3GBとされ、サイズが0x1d4c00000とされたことから、0x01EA6000までしか使えないみたいです。

書き換えが完了したらツール「RK3xxx_firmware_tools_5.99.07.00」右上のファームの「Build」ボタンを押しましょう。ツール実行フォルダに「firmware_new.img」という名前で修正後のイメージファイルが出来上がります。
これを「RKBatchTool v1.7」でDG-Q10Sに書き込むと、書き込み完了とともにシステム再構築が開始します。数分間待ちましょう。

起動したら設定のストレージを見て確認しましょう。あと、ADB環境をお持ちのかたdmesgやdfなどパーティションの様子が分かるコマンドを発行して確認してみてください。
筆者の場合を以下に抜粋で貼り付けておきますね。

■修正前■

root@android:/ # df
Filesystem             Size   Used   Free   Blksize
/dev                  442.7M  36.0K  442.7M   4096
/mnt/asec             442.7M  0.0 K  442.7M   4096
/mnt/obb              442.7M  0.0 K  442.7M   4096
/system               511.6M  399.1M  112.5M   1024
/data                 1007.9M  385.1M  622.8M   4096
/cache                124.0M  16.1M  107.9M   4096
/mnt/external_sd      14.9G  255.8M  14.7G   32768
/mnt/sdcard           13.6G  99.0M  13.5G   8192
/mnt/secure/asec      13.6G  99.0M  13.5G   8192

root@android:/ # cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00400000 00004000 "misc"
mtd1: 00c00000 00004000 "kernel"
mtd2: 01000000 00004000 "boot"
mtd3: 02000000 00004000 "recovery"
mtd4: 04000000 00004000 "backup"
mtd5: 08000000 00004000 "cache"
mtd6: 40000000 00004000 "userdata"
mtd7: 00400000 00004000 "kpanic"
mtd8: 20000000 00004000 "system"
mtd9: 364400000 00004000 "user"

root@android:/ # cat /proc/partitions
major minor  #blocks  name

 179        0   15663104 mmcblk0
 179        1   15651246 mmcblk0p1
  31        0       4096 mtdblock0
  31        1      12288 mtdblock1
  31        2      16384 mtdblock2
  31        3      32768 mtdblock3
  31        4      65536 mtdblock4
  31        5     131072 mtdblock5
  31        6    1048576 mtdblock6
  31        7       4096 mtdblock7
  31        8     524288 mtdblock8
  31        9   14225408 mtdblock9

root@android:/ # dmesg（抜粋）
<5>[    0.000000] Kernel command line: console=ttyFIQ0 androidboot.console=ttyFIQ0 init=/init initrd=0x62000000,0x00120000 mtdparts=rk29xxnand:0x00002000@0x00002000(misc),0x00006000@0x00004000(kernel),0x00008000@0x0000a000(boot),0x00010000@0x00012000(recovery),0x00020000@0x00022000(backup),0x00040000@0x00042000(cache),0x00200000@0x00082000(userdata),0x00002000@0x00282000(kpanic),0x00100000@0x00284000(system),-@0x00384000(user) bootver=2013-05-18#1.20 firmware_ver=4.1.1

■修正後■（ある程度アプリとデータを入れた状態です。）

root@android:/ # df
Filesystem             Size   Used   Free   Blksize
/dev                  442.7M  36.0K  442.7M   4096
/mnt/asec             442.7M  0.0 K  442.7M   4096
/mnt/obb              442.7M  0.0 K  442.7M   4096
/system               511.6M  401.2M  110.4M   1024
/data                 7.1 G  1.0 G  6.1 G   4096
/cache                124.0M  16.1M  107.9M   4096
/mnt/external_sd      14.9G  8.0 K  14.9G   4096
/mnt/sdcard           7.3 G  1.7 G  5.6 G   8192
/mnt/secure/asec      7.3 G  1.7 G  5.6 G   8192
/mnt/asec/com.cyandroid.piano-1  2.0 M  432.0K  1.6 M   4096
/mnt/asec/jp.co.apurimajin.eye-1  13.2M  11.7M  1.5 M   4096

root@android:/ # cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00400000 00004000 "misc"
mtd1: 00c00000 00004000 "kernel"
mtd2: 01000000 00004000 "boot"
mtd3: 02000000 00004000 "recovery"
mtd4: 04000000 00004000 "backup"
mtd5: 08000000 00004000 "cache"
mtd6: 1cf800000 00004000 "userdata"
mtd7: 00400000 00004000 "kpanic"
mtd8: 20000000 00004000 "system"
mtd9: 1d4c00000 00004000 "user"

root@android:/ # cat /proc/partitions
major minor  #blocks  name

  31        0       4096 mtdblock0
  31        1      12288 mtdblock1
  31        2      16384 mtdblock2
  31        3      32768 mtdblock3
  31        4      65536 mtdblock4
  31        5    2097152 mtdblock5
  31        6   12582912 mtdblock6
  31        7       4096 mtdblock7
  31        8     524288 mtdblock8
  31        9     724992 mtdblock9

root@android:/ # dmesg（抜粋）
<5>[    0.000000] Kernel command line: console=ttyFIQ0 androidboot.console=ttyFIQ0 init=/init initrd=0x62000000,0x00120000 mtdparts=rk29xxnand:0x00002000@0x00002000(misc),0x00006000@0x00004000(kernel),0x00008000@0x0000a000(boot),0x00010000@0x00012000(recovery),0x00020000@0x00022000(backup),0x00040000@0x00042000(cache),0x00200000@0x00082000(userdata),0x00002000@0x00282000(kpanic),0x00100000@0x00284000(system),-@0x00384000(user) bootver=2013-05-18#1.20 firmware_ver=4.1.1

さて、必要なところに十分な領域を確保できてかなり動きはサクサクになりましたが、何せ初期のNAND FLASHですから、いずれ遅くなってくるのは間違いの無いところでしょう。領域変更は遅くなるタイミングを（かなり）遅くにずらせるだけです。
また、幾らサクサクと言っても、書き込み処理が込み入った時には結局分単位で固まってしまうことになります。これを予防するためには書き込み頻度を下げる工夫が必要になります。例えば、必要が無いのであれば同期や通知、バックアップなどとことん切ってみましょう。
NAND FLASHの書き込みとは関係無い気がしますが、開発者オプションでアニメーションの類を全てオフにするのも地味に効果があります。

そうして使ってみて、遅くなってきたなと思ったらTrimアプリの出番です。筆者はTrimmer(fstrim)を使用させていただいています。
幸い、DG-Q10Sは余計な制限を加えられていないため、Trimアプリが普通に使えます。これを使うとCacheやUserdataの未使用領域を未書き込み領域にしてくれるので、サクサクを取り戻せます。

領域変更で遅くなりにくくし、Trimアプリでサクサクを取り戻す。このコンボでこのDG-Q10Sの使い勝手は以前とは比べ物にならないほどアップ。かなりまともに使えるようになります。
同時期のスマホやタブレットで同じような現象に悩まされている方がいたら、このような手法でサクサクを手に入れられるかもしれません。実際の手段は搭載されているSoCで違ってくると思いますし、rootが取れているかどうかで必要な作業が変わったり、あるいは作業できなかったりするかもしれませんが、方法論としては、上記のやり方が参考になるのではないかと思います。