台湾ROMを積みドコモXi SIMカードを挿したHTC J ISW13HTからSMSを送信する

自分のメイン端末のHTC Jは台湾ROMではXi SIMカードを使っている場合、普通の方法でSMS送れない。このことは「ISW13HT HTC J、Sense4.1ポートROMについて (HTC速報Dev)」で、このROMを編纂した方本人が書いておられる。ソフトバンクSIMカードなら問題ないようで癪だ。

そのページにコメントの中にも書いたが、Beyond SMSというアプリXDAでのスレッド)を使えば可能。単なる「ドコモ以外のスマホからドコモのSIMでSMS送信をすると失敗するようだが”validity period ”を設定可能なSMSアプリなら送信できるようだ」の受け売り。ただ、Beyond SMSはSMSアプリの置き換えを意図しているわけではなく、プログラム的に操作しようとすると(例えば特定のイベントで自動的にSMSを発信する、など)簡単ではない。

さて、最近Xposedを試しにインストールしてみたときに、XposedのモジュールにXposedSendRawSMSというのがあるのを知った。これは、かつてはAndroidのAPIの一部であったsendRawPduを使用するもので、それはBeyond SMSと同じ。sendRawPduはその後のAndroidのバージョンで廃止されてしまったようなのだが、一部Androidデバイスのモデルでは、製造会社が意図的に残しているらしい。自分のHTC Jはたまたまそういう端末であったため、Beyond SMSが使える。つまり、XposedSendRawSMSも使える可能性が大。

XposedSendRawSMSの中身を見てみると、核となるのはModSmsMessage.javaのようだ。リフレクションを使ったコードなんて久しぶりに見た。XposedSendRawSMSは、sendRawPduのパラメタを自由に設定した上でSMSを送れるようにするのがその目的だが、自分の場合そんなことはできる必要はなく、validity periodを決め打ちで変更できればいいだけ。なので、XposedSendRawSMSをいわば機能縮小したモジュールを作成すれば、普通のSMSアプリを使って、普通にSMSの送受信ができるようになるのではないか。

以下参考:

 

 

HTC J ISW13HTにXposedを導入してみた

HTC J ISW13HTに台湾ROMを焼きさらにWCDMA (UMTS)化をしてドコモのネットワークで使っている。自分の用途には十分なパフォーマンスで概ね満足しているが、電池の管理には少し不満があった。通知エリアに表示されるピクトグラムではまだそこそこ電池に残があるように見えていても、突然「あと9%です」とかいう通知があって、手を打たないと、と思うまもなくシャットダウンしてしまう。ピクトグラムではなく、はっきり残量をパーセント表示で見たい。

Xposedというルート化済み端末向けのカスタマイズ機構で実現できそうだ、と考えて、以下を参照にやってみた。

Frameworkをインストールして初期化した際、Segmentation faultが起こる、ということで、busyboxバイナリを含むインストーラーで再度インストールすることを求められた。

さて、Xposed Module Repositoryを見たりしながら自分の用途に使えそうなモジュールをインストールして試してみたが、うまくいくものがなかなかない。モジュールはJelly Bean以降を対象としていることが多いようで、ICSのこのROMには適用できないのかもしれない。

そこそこ時間を費やして試しまくり、やっと目的を達成してくれたのは、Ex-Themer[ICS/JB][ A Warehouse Of Android Themes ]

が…数字表示の数字が小さくて読みにくい…。てか、読めない。ああ、嫌だよ老眼、激しく嫌

結局、XBatteryThemerという普通のアプリを使うことにした。しかも、その後、SDカードの問題でシステムの初期化をしなくてはならなかったので、Xposedフレームワーク自身今は全く使わない状態になってしまった。

参照:

DLNA/UPnP AV DMSs and Playlists

Yet another old and only-half-finished article, which I am publishing anyway. On the topic, I ended up using Playlist Creator on the file system from which our primary DMS serves its contents. Using relative paths, of course.


It turns out that the DLNA/UPnP AV standards do not provide systematic support for server-side playlist management, which I find utterly surprising. Aren’t there obvious needs for that?

Some DMSs pick it up if there’s a playlist file while scanning their media libraries in file systems, but there does not seem to be any predefined protocol through which you can manage playlists; you can only do that on the file system you are exposing to DMSs. For example, here is a way to do it for MiniDLNA servers. Also, here’s a list of playlist creation tools.

Some DMPs, DMRs and DMCs do support playlists, but not in a collaborative way. Normally those playlists are never propagated elsewhere and stay isolated, confined only inside that particular device/app.

If they should be propagated at all, that happens only between, say, a DMS and a DMC that are designed to work together from the get-go, but not between other devices/apps. Since there is no support for it from the DLNA standards themselves, the interoperability does not exist.

That is why I was very much intrigued by BubbleUPnP Server. It is not a DMS by itself, but it works as a proxy to existing DMSs and provides additional functionality, such as transcoding and remote access.

I am sure some would consider it useful enough for those additional benefits, but I was more interested in the fact that it can also create an OpenHome compliant renderer, acting as a proxy to an existing DMR .

I’ll be honest here — I am not still quite sure what OpenHome is. My first impression was that it is a home automation framework (on a related note, I wrote “Home Automation Systems and Intercoms” before). iControl Networks does present it that way. At any rate, OpenHome includes an arm on home media management called OhMedia, which supposedly addresses the flaws of the UPnP AV standard. Each of the claims seems legitimate, but my take on it is that they should be addressed by augmenting the UPnP standard, not by creating a separate standard. At any rate, OhMedia offers the playlist management functionality, and that is the additional benefit you get by creating a OpenHome compliant DMR with BubbleUPnP Server.

Initially, I thought that was exactly what I wanted, but then realized it wasn’t. The server maintains playlists on its side on the per-renderer basis. Is this what people normally want? Don’t we rather want playlists that are not bound with a particular renderer?

Sure, since you can start playing a playlist on a renderer and then switch the renderer midway, you could potentially create playlists for a “catch-all” renderer and use its playlists as “renderer-unbound” playlists. But I find this solution conceptually unnecessarily complicated and methodically awkward. (I’d also think the initial renderer needs to be present at all times for this scheme to work.)

So, okay, the verdict is in: BubbleUPnP Server is not for me. At least with regards to the server-side playlist management, that is. I might use it for its transcoding and remote access capabilities.

The other option I considered is Twonky Server (Packet Video’s explanation of Twonky Server) combined with Twonky Manger.

You can create playlists with Twonky Manager running on your Windows PC or Mac (no Linux) for Twonky Server. Those playlists will be shown on your DMC/DMP in a Playlists folder. If you are running Twonky Server on a Windows PC, the playlists made on that PC in Windows Media Player will be shown alongside.

The fact

The Android app Twonky Beam’s UI is not quite user friendly. It does not allow playing videos on an external player, thus limiting the codecs it can handle.

In the Windows version, those playlist data are stored at a specific place. Since Twonky Server offers WebDAV access, I wonder why you cannot just place those playlist files directly in such a way that those playlists can be utilized even when the media contents are served by other servers.

One interesting feature of Twonky Server is to aggregate media content from other DLNA servers. I was surprised to learn that it can download DTCP-IP mpegs from the over-the-air digital TV tuner with recording capabilities.

Comparison of UPnP AV media servers

Universal Media Player, derivative of PS3 Media Server

 

Android端末でApp2SD機能によりSDカードに追いやったアプリが消えたり現れたり

先週末にはまった話。

自分のメインのAndroid端末でそのApp2SD機能によりSDカード(厳密にはmicro SDHCカードだがここでは簡単に「SDカード」と呼ぶことにする)に追いやったアプリが消えたり現れたりする、という現象が起こるようになった。再起動で解消することもあれば、そうでないことも、という状態。

件のSDカードは2つのプライマリ・パーティションに分けてあった。第1パーティションはFAT32でフォーマットしてあり、Androidからは普通の外付けSDカードはカードの扱い。2つ目のパーティションはExt4でフォーマットしてあり、Link2SD用に使っていた。

最初は、SDカードのマウントそのものに失敗していると思い込んでしまった。実は第2パーティションは問題なくマウントされてLink2SDによりそこに格納されたアプリは使えていた。第1パーティションも全くマウントされないのではなく、App2SD機能でSDカードに追いやったアプリを格納する/mnt/asec以下がダメなだけで、それ以外の普通のファイルは問題なくアクセスできた。

このしょっぱなの現状把握の段階で誤ってたので時間をだいぶ浪費した。これに気づく前に、たまたま用意していてた新しいSDカードに総入れ替えして置き換えてみたが同じ症状だった。

App2SDの動作の仕組みとか調べてみたが(簡単な説明もう少し詳しい説明(ディレクトリ名などは古い))、だからどういう原因でこういう現象が起きていて、どう対処すればいいかまでわからない。Link2SDは動作していたので、App2SDはもう使わないようにして全てLink2SDにしてもよかったが、気持ち悪いので以前この問題が起き始める前にCWMリカバリーでバックアップしていたデータをリストしたが /data がリカバーできないというエラーが出る。これは想定外。何のためのバックアップかわからない。

もうしょうがなくROMの焼き直しで初期化。

Link2SD用の第2パーティションはそのまま。つまり、初期化してもそのパーティションは削除されないので、その後Link2SDをインストールして、(ルート化が必要だが)それによりしかるべきマウントスクリプトを導入すれば、それらアプリはすぐ再使用できるようになる。第2パーティションにAPKがあっても、Link2SD自身が認識できていないとそれに相当するアプリは使えないので、Link2SDのオプションの「全てのアプリを再リンクする」を選択し、その後再起動すればその後それらアプリは使えるようになる。

ただ、無料版のLink2SDではアプリの内部データまではSDカードに移せない。なので、上記のようにして、初期化後も以前のアプリが使えても、肝心の設定データ等が失われてしまう。有償のLink2 SD Plusを購入すれば、内部データまではSDカードに移すことが可能になる。予めそうしておけば、今回のように初期化を経ても、設定データ込みで以前のユーザーアプリがすぐ使えるようになるはず…と期待している(未確認)。

しかし、何が悪かったのかわからないが、また最初の問題が発生するようになってしまった。

ここで、App2SDによりSDカードに移されたアプリが格納されている/sdcard/.android_secureディレクトリの名前を、ものは試しでリネームしてみた。Android OSが立ち上がっている状態ではこれはrootでもマウントを解除したりしなければできないので、CWM Recoveryで/sdcardをマウントをした状態でadb shellでroot権限にて行った。その後端末を立ち上げると、システムが自動的に/sdcard/.android_secureを作成するのだが、その上でApp2SDを行うとうまく行っているように見える。

ちなみに、初期化してしまったのでTitanium Backupから取ってあったバックアップをリストアしようとした。そのため、Titanium BackupをPlayストアから再インストールしようとしたが、何度試そうと「容量が不足」エラーでインストールできなかった。結局、/data/以下に元々はLink2SDが作ったと思われるシンボリックリンクが残っていたのが原因で、これを削除すると無事再インストールできた。その他の一部アプリに関しても同様の状態になっていたので、久しぶりに書いたスクリプトでこれら無効なシンボリックリンクを削除すると、問題なくリストアできた。

今は、アプリのSD移動は基本Link2SDでExt4の第2パーティションに移すことにしている。その上でテストを兼ねて、使えなくなってもすぐには困らないようなアプリをAndroidネイティブのApp2SD機能でFat32の第1パーティションに移している。その後数日経つが、今のところ安定して動作しているようだ。

考えてみると、この問題が起こっているときは、端末が異様に熱くなっていた。App2SD機能の実現には複数のmountが使用されているが、これが何らかの理由でうまくいかず、何度もリトライでもしていたのだろうか。