「 2009年06月 」一覧

PCパーツのリサイクルはどうすればいいのだろう

デスクトップPCはもう10年近く自作してきてて、CPUをアップグレードしたりしたときに余ったマザーボードやグラフィックカードなどがそれなりにある。

もう動くかどうかも分からないし、そもそも需要も無いだろうし処分しようと思っているのだけど、単に燃えないゴミとして出すのもレアメタルがどうこうという話を聞いたことがあるので何となく気が引ける。もしきちんとリサイクルしてくれるところがあればそんなところに処分をお願いしたいなぁ...と。

ちょっと調べてみると、インプレスの記事にも出ている、パソコンファームってところがあった。ちょっと見た感じPCパーツのみバラバラで送って大丈夫かどうか分からないけど...。

ググってみると、人力検索、Q&A系のサイトもよく引っかかるのだけど、ほとんどの回答が「ヤフオク」「ソフマップ」「燃えないゴミ」なんだよね...。質問者は「古いパーツ」とか「手間をかけずにリサイクルしたい」って書いてあるのに、何だかその意をくんでない回答が多すぎる気がする。

もう動作するかどうか分からないのをヤフオク出すのも面倒。いちいち発送とかしないといけないし、数百円それで手元に入ってもね...。それに買取もちょっと年数が経った物は買取不可がオチだし。

とりあえず業者系をもう少しリサーチしてみる予定。


iPhone3GS欲しい

次の機種はiPhoneにしようかと考えていたら、3GSがけっこう良い感じ。

まぁ、今の割賦が11月まであるのですぐに機種変というのはお得じゃ無さそうね。Twitterで教えてもらったのは新規契約がお得らしいということ。今の端末は割賦が切れる11月までほぼ冬眠させておくってことね...。

iPhoneも今すぐ欲しいというわけでもないので、キャンペーンやってる間に買えばいいかな。

あ-、新規だと電話番号が引き継げ無いのかな?んー、ちょっとそれは困るかも知れないな。そうすると機種変しか無いのか...?


WWDC

最初のMacbookProのアップデートの発表が終わったところで寝てしまった。

結局、SnowLeopardは9月、iPhone 3GSが発売ということになったのね。

SnowLeopardが9月に延びても、値段が$29ならそれ搭載のハードの買い控えはあまり起こらないと踏んでMacbookProのアップデートを先にやったんだろうか。

でもこのタイミングだと9月にはSnowLeopardプリインストールモデルが出るわけで...。そこまでまたハードスペックの微変更が入る可能性が高そうだしな。


AndroidのフルソースからビルドしたエミュレータでSDを認識しない場合

タイトルそのままなんだけど、私の環境で発生して解決できたようなのでメモ。

AVDを使わずに、フルソースをビルドして出来上がった各種イメージファイル(out/target/product/generic/system.imgなど)を使ってエミュレータを起動した場合(emulatorのパラメータで-system/-ramdisk/-kernelなどを付けたとき)、-sdcardでSDイメージファイルをちゃんと指定していてもエミュレータがSDイメージを認識せずに「SDが刺さっていない」ことになってしまうことがあるようだ。

mksdcardでイメージを作り直したりしても同じで、しばらくハマっていたところで本家フォーラムで回避策を発見。

Cupcake Emulator do not mount SD card image - Android Developers | Google グループ

実際のバグトラッキングページはこちら↓。

Change 9452: Ensure that /system/etc/vold.conf is created in the "generic" product. This is necessary to let the emulator mount SD Card images properly through the "vold" mounting daemon | review.source Code Review

どうもソースをmakeしたときに、out/target/product/generic/system/etc/ の下にvold.confというファイルが作成されないかららしい。

ちなみにvold.confの中身はというと、

## vold configuration file for the emulator/SDK

volume_sdcard {
    ## This is the direct uevent device path to the SD slot on the device
    emu_media_path /devices/platform/goldfish_mmc.0/mmc_host/mmc0

    media_type     mmc
    mount_point    /sdcard
    ums_path       /devices/platform/usb_mass_storage/lun0
}

と、SDのマウントの設定が書かれている。これが無いとそもそもエミュレータがSDを認識しないようになってる模様。

さてvold.confが正しく生成されるために、ここにある差分をマージする。

diff --git a/core/main.mk b/core/main.mk

--- a/core/main.mk
+++ b/core/main.mk

@@ -209,6 +209,14 @@ ifeq (,$(filter %:system/etc/apns-conf.xml, $(PRODUCT_COPY_FILES)))
     $(warning implicitly installing apns-conf_sdk.xml)
   endif
 endif
+# Install a vold.conf file is one's not already being installed.
+ifeq (,$(filter %:system/etc/vold.conf, $(PRODUCT_COPY_FILES)))
+  PRODUCT_COPY_FILES += \
+       development/data/etc/vold.conf:system/etc/vold.conf
+  ifeq ($(filter eng tests,$(TARGET_BUILD_VARIANT)),)
+    $(warning implicitly installing vold.conf)
+  endif
+endif

# If we're on an eng or tests build, but not on the sdk, and we have
# a better one, use that instead.
ifneq ($(filter eng tests,$(TARGET_BUILD_VARIANT)),)

パッチ適用後もう一度makeすると、vold.confが生成される。またsystem.imgも更新されるようだ。

これでエミュレータを起動すると、今度はきちんとSDが認識されるようになる。

...これで半日くらい潰した...。


Android解析進まず

週末もいろいろAndroidの解析をやってみたのだけど、ほとんど進んでない。

一番知りたいSurface周りはまったくと言って良いほど。Surafce,ISurface,SurfaceComposer,SurfaceComposerClient,SurfaceFlingerなど関連クラスがいろいろあるのだけど、その関連性もよく分かってないまま。

システム構成には"SurfaceManager"というSurfaceの重なりなどを司っている部分があるはずで、単純なSurfaceオブジェクトをManagerの管理下に置かないといけないのか、置くための手順はあるのかなどなど謎が多い。

ついでにSurfaceを内部で扱ってる感じのVideoViewとCameraクラスを見てるんだけど、これ内部でSurfaceクラスとのフレンドクラス指定とかやってるんだよな...。

Surface::getISurface()を使うためらしいんだけど、フレンドクラス指定とかやられると、第三者が似たような機能のクラスを作るとすると、Surfaceクラスの元ソースにfriendを入れないといけないってことだよなぁ...。うーん、元ソースは汚さずに拡張したいんだけどなぁ。

あとは、エミュレータでのNativeフレームワークのデバッグ方法について。かなり頑張ってみて、少し光が見えてきた感じ。フルソースをビルドするとシンボルが別個に生成されるのでそれをGDBに読ませれば大丈夫そう。


クールビズ

6月からクールビズが始まった。今年で5年目らしいね...。

なんとなく毎年何を着ようか微妙に迷う。クールビズなんてそんなに着る物の選択肢は無いんだけど、色づかいとかどうも自分にはしっくり来ない物もあったりするので、スーツの上着を着ないだけのような格好に落ち着くことが多い。

半袖シャツなんかも何となくオヤジくさい感じがして去年まで着なかったし。自分に合う組み合わせを本気で考えたほうがよさそうだな。

シャツはまぁユニクロあたりに行けばそれっぽいのはいくらでも安く手に入るんで、だいぶ便利にはなったけど。


Androidのコア部分のデバッグは…?

AndroidのNativeのシステム、ライブラリなどのデバッグをしたいのだけど、やり方が今ひとつわからない。

gdb使うのは間違いないけど、ソースレベルデバッグするためのシンボルとかはあるんだろうか。フルソースをビルドすると作られたりするのかなぁ...?

やりたいのは、エミュレータにgdbリモート接続して、mediaserverなどの動きを見たいのよね。

自分で作ったNativeモジュールなら、gcc -g でデバッグ情報埋めたものをエミュレータに転送すれば大丈夫そうなんだけど、システムモジュールはどうなんだろうと。

ソースだけ追っていても動作が分かりづらいのでデバッグトレースしたいと思ったのだけど、gdbの経験が無いからかさっぱりやり方がわからない。


AndroidのNative層でのログ出力

まだ調査中だけどとりあえず動いているのでメモ。

(1)LOG出力の際のタグの定義と、Log.hのインクルード
warningが出るのでLOG_TAGはundefしておいたほうが良いはず。

#define LOG_TAG "JNI-Test"
#include <utils/Log.h>

ちなみにLog.hの場所は以下。

frameworks/base/include/utils

(2)Android.mkにlibutilsとlibcutilsをリンク対象に含める
これを含めないとLOGV()でログが出力されなかったり、LOGD()やLOGI()を使おうとするとビルドエラーになったりする。
ちなみにEnabling LOGD messages in Webkit - Android Developers | Google グループでのやり取りを参考にした。

LOCAL_SHARED_LIBRARIES:= \
    libutils\
    libcutils

(3)LOGD()やLOGI()などをコードに埋め込む
GDBでデバッグが面倒な時もあるのでログは重要だと思う。LogCatで手軽に見ることができるので。


Androidのソースツリー内にあるJNIのサンプルソース

AndroidでJNIを使うサンプルがソースの

development/pdk/ndk/samples/samplejni

以下にあるのを発見。

NDKというのが、"Android Native Development Kit"といってShared libraryを作るための一式らしい。samplejniサンプルは、.soを含んだ.apkを作るところまでのサンプルになっているようなので、アプリパッケージにNativeのライブラリモジュールも含めたい場合には参考になるかも。

あと、javahを使ってヘッダファイルを生成せずに、JNI_OnLoad()から動的にJNIに関数を登録する方法のサンプルにもなるかな。

ただ、まだNative層のライブラリのドキュメントが整備されていない(?)*1ので、ほかのソースを見ながら手探りでやっていくしかないんだけどね...。

  • *1: なんだかdoxygenのconfigが入ってるのでdoxygenで生成できたりするんだろうか


スポンサーリンク