• LinuxCon
• Androidのプロセス間通信
• メソッドのインボケーション
• ashmen
• system propertiesの管理が面白い
• 起動時のPSコマンド（途中省略）
• ３０個のプロセス
• →２００個のスレッド
• 互いに通信するプロセス
• 概念図
• Activityが起動するときはマネージャーからの指示で動く
• 他のシステムとやり取りして動いてる
• →カーネルが提供するシステムコール
• プロセス間通信の抽象的な度合い
• Binderが一番濃い
• AIDLがマップ
• Intentが一番抽象的
• ashmem
• →共有メモリ
• Intentに関して
• リクエストはキューイングされる
• →順番に実行されるからマルチスレッドは簡単
• かなりパワフル
• inter process method呼び出しで実装される
• Intent
• loosely coupling
• とりあえず投げるだけの実装
• →システム内で適切なのが処理してくれる
• →Actionでもっと面白い動作ができる
• 　View + "http://〜"　→ ブラウザが起動
• 　VIEW + "geo:0,0?q=Tokyo"
• システムサービスで使われている
• メソッド間呼び出しはマルチで呼ばれる
• →マルティスレッドを考える
• AIDLつかうよ
• インターフェースを利用したメソッド呼び出し
• callerとcaleeの関係
• インターフェースで実装は切り離される
• どうやってつながってる？
• プロセス間はカーネルのバインダーを使う
• proxyでメソッド間を呼び出す
• BinderThreadが待ってる
• ビットシーケンスをjavaのオブジェクトの形になおしてcalleeを呼ぶ
• returnValeeは逆の処理を行ってcallerへ渡す
• android.os.parcel
• オブジェクト知り洗いジェーションを伝統的には使うがandroidは違う
• メモリ空間も別
• flatten
• 立方体をバラしてFAXで送って、受信側で組みたてるイメージ
• UMLで表した形
• ProxyとStubがinterfaceを実装
• CallerはInterfaceを知ってる。
• CalleeはStubを実装している。
• みするとバグがよくわからなくなる
• →AIDLを利用して解決している
• 　→ProxyとStubは自動的に生成される
• プロセス間メソッド呼び出しの例
• Activiyがポーズするときの例
• １、schedulePauseActivity
• ２、binderThreadが待ち受ける
• ３、Looperで実行する
• Binderはカーネルのデバイスドライバ
• /dev/binder
• 特定用途にチューニングされている
• マルチスレッドに特化している
• socketと比較
• 伝統的 rmi
• 　ソケットで呼び出し
• なぜ特別なドライバを用意したのか？
• どこまでよみかきしたのか？
• 　binderはプロセスごとに保持される
• 　FDを同じプロセスごとに共有できる
• よみかきはどうする？
• 　ソケットはstream
• 　バインダーは一度のioctlでよみかき
• 　　オーバーヘッドが減る
• ネットワーク
• 　透過性はある
• 　バインダーはローカルのみ
• ioctlでトランザクション
• 　ストラクチャでw/rのバッファがある
• 　→一回ですむ
• ローカルに特化しているから
• 　プロセスA　プロセスB
• 　メモリは別空間
• 　→カーネルが管理してあげる必要がある
• 　→カーネルへコピー
• 　　スケジューリングして別プロセスでコピーする
• 　memcpyみたいなもん
• 　もどるときは同じようなことを逆向きにする
• ashmem
• 　Android / Anonymous SHared MEMory
• 　pin / unpinというAPIが特徴
• 　→メモリ管理でよく出る言葉
• 　→コルクボードで虫ピンで指す
• 　　→風で飛ばない
• 　　ただ置いてある
• 　　→風でふっとぶ
• 　create_regionで作る
• 　pinされたメモリは消えない。
• 　pinされていないメモリは再利用される
• 　キャッシュはunpinされて保持される
• 　→システムメモリが足りなくなってきたらカーネルが判断して開放される
• システムプロパティ
• 　キーパーリューストア型のデータベース
• 　すべてのプロセスで共有
• 　initが代表
• 　その他はコピー
• 　書き換えるときはinitへ要求する
• 　froyoまではashmemで実装されていた
• 　神社では標準のシステムコールだけで実装された
• 　→ashmem使う必要なかった
• getprop
• 　どんなプロパティがあるか確認できる
• 　ro.*はリードオンリー
• 　init.svc.*はinitが作ったサービスの動作状況確認ができる
• 　ctl.start / ctl.stopは特別
• 　　サービスをスタート／ストップするのに使用される
• システムプロパティの構造
• 　/dev/__properties__
• 　テンポラリファイル
• 　init →　mmap(r/w)
• 　他→ mmap(r/o)
• 書き換え方
• 　initへsocket経由で送信する
• 　変更したら他のプロセスへ伝播する
• 　Android以外でもいける
• 実装
• 　システムコールで生成
• 　ファイルサイズを確定
• 　initではr/wでmmap
• 　一旦FDを閉じる
• 　同じものをr/oで開く
• 　環境変数へFDを保持すると他のプロセスへ反映される
• 　子プロセスには直接各方法がない
• 　unlinkすることで削除する
• 　→ファイルを開いてアクセスする方法がなくなる
• 　→init経由でアクセスすることしかできなくなる
• 参考例
• デモは無し
• 会場での質問
• 　まごろくさんが質問
• 　binderはBeOSから来ている？
• 　→Androidからだから、よく知らない。違うらしい。
• 　村上さん：Binderはメッセージキューの代替？
• 　IPC
• 中途半端な状態でプロセスが死んだ
• 　ちゃんと処理するハンドラが用意されている
• 　binderはsocketより使いやすい？
• 　→単独であるわけじゃない
• 　　用途を実現する為に実装されているから必要以上な処理は実装されていない。
• 　　汎用な通信をカーネルで用意するからユーザーランドで使ってくれよ！
• 　　突き詰めるとローカルならメモリコピーで通信できるじゃん

• 自己紹介
• @cooseezzz くーしーさん　組込み系な人
• 端末いっぱいな人　８台
• C、アセンブラな人
• まごろくさんのディスプレイサブシステムで質問したら調べて発表してとなった
• コードを追いかける発表
• SurfaceFlingerはC++
• 2.2.2_r1参照
• SFとは？
• Process
• 　system_serverプロセス内のスレッド
• 　出てきたスレッドいっぱいで手が回らない
• Function
• 　複数のサーフェイスを重ねあわせてフレームバッファを構成する機能
• Interface
• 　アプリからのつなぎはSurfaceに関するリクエストをBinder経由で受け付ける
• 　HAL層はgralloc党を経由してashmem、pmemを使ってる
• 前回のまごろくさんの資料の引用
• 　アプリからSurfaceへ何らかの操作
• 　Binder経由でSFへリクエスト
• 　SFはSurfaceの関係を処理してフレームバッファへ投げている
• SurfaceとLayer
• 　アプリ側ではSurface、SFではLayerとして対応している（たぶん）
• Region
• 　Surface、やLayerの矩形領域に関する情報
• おしながき
• 　JNI〜Surface関連のメソッド呼び出しの流れ
• 　SFの起動からthreadloopまで
• native関数の登録
• 　frameworks/base/core/jni/android_view_surface.cpp
• 　まずサーフェイスセッションの接続を確立する処理をする
• 　その後、サーフェイスに関する処理を行う
• gSurfaceMethods
• 　Java側とNative側をヒモ付している
• JavaのSurfaceクラス
• 　Native側に対応するメソッドが書かれている
• Surface_init
• 　SurfaceComposerClient* client
• 　client->createSurfaceからSurfaceFlinger::createSurfaceに繋がっている？
• 軽い気持ちじゃ・・・
• ソース解説
• sp
• 　ストロングポインタ
• 　　弱い参照、強い参照
• 　　→読み飛ばす
• NUM_BUFFERは２
• Androidはダブルバッファ
• SFの起動からthreadloopまで
• /main_surfaceflinger.cpp
• readyToRun
• 　ディスプレイ関連の初期化
• 　OpenGL ES関連の初期化
• 　起動アニメーションの開始
• 　　property_set("ctl.start", "bootanim");
• 初期化内のTips
• 　property_get("ro.sf.lcd_density", 〜)が定義されてなかったら160dpiで初期化してる
• threadloop
• handlePageFlip
• 　lockPageFlip
• 　　SharedBufferをロックしてフロントバッファとして扱う
• 　　　Layer枚にSharedBufferを２面もつ
• 　dirtyな領域を計算する
• 　　dirtyはコードでよく出てくる。どうゆう状態を指すかはっきりとはわからなかった。
• 　Layerの矩形の幅、高さの変化を確認する
• 　　drawingStat()とcurrentStat()
• 　　可視領域の再計算の準備をフラグをtrueにして行う
• 　テクスチャの更新
• 　　reloadTexture();
• 　これらの処理を各Layerに行う
• computeVisibleRegions()
• 　上にあるLayerから順にopaqueRegion（不透明）、visibleReqion（半透明含む）、coverdReqion（覆われて見えない）の分類
• 　オペック
• handleRepaint
• 　Dirtyな領域の更新方法を決める
• 　デバイス情報？をもとに決定
• 　部分更新でOK：mDirtyRegion.set(mInvalidRegion.bounds())
• 　全体：mDirtyRegion.set(hw.bounds())
• composeSurfaces()中でLayer毎に以下を行う
• 　現描画の取り消し
• 　可視領域に対して描画
• hw.compositionComplete
• 　フレームバッファの準備が完了したことをハードへ通知
• 　fdDev->compsitionComplete()
• 　この先でHAL層の関数に繋がる
• fdDevの先にある物
• 　gralloc.h
• 　framebuffer.cpp
• unlockClient
• 　SharedBufferStackのアンロックをLayer毎に実行
• postFramebuffer()
• 　fdDev->
• 　HAL層へ繋がっている
• threadloop else節
• 　else節は1/60秒スリープ
• 　elseじゃないほうでVSYNCするか等は多分HAL層以下に依存する
• 　　S*社端末など、ベンチマークで３０FPSしかでないものもある
• 　　サムスンは違う。
• 　　旧Xperiaは３０FPS。
• 　　　電池持ちを良くするため？
• 　　SHの端末もベンチをすると遅い
• 　　　描画が間に合わないから？らしい
• 質疑
• 　前半と後半でどっちが時間かかる？
• 　　前半はBinderの仕組みじゃないかな？
• 　Surface　アプリに割り当てる画面だけど、LayeyとSurfaceとのかかわりはどうなってるの？
• 　　対応はしているはず。ソースないでLayerのソースなのにSurfaceのコメントが出てくる。
• 　　よくわからない。

会議アプリ：GoToMetting

• 結構複雑
• さわりだけ行っていく
• 何？
• 　３つの機能
• 　　静止画の撮影
• 　　動画の録画
• 　　ファインダービューの取得
• 　　　プレビュー。ARとかプレビューに画像処理する場合はこれを利用する
• 　うえ２つはプログラマには解放されていない
• 　ハード依存とAPI
• 　　共通のAPIを機種毎に異なるハードで実装
• 　　　カメラはメーカー最後のフロンティア
• 　　レイヤを分けて設計実装
• 　調べ方
• 　　BeagleBoardでのUVCカメラの動作をトレースするのが近道
• 　　0xdroidまたは天使ちゃんのWebサイトへ
• レイヤ
• 　Camera Service
• 　　MediaServerの１スレッド
• 　Camera HardwareIF
• 　　AndroidHALのIF部。機種依存はない
• 　Camera Hardware
• 　　HAL部　機種依存する
• 　　オープンソースはフェイクになっている
• 　　　カメラで静止画とると変な画像がとれるのはそのせい
• 　V4LCamera
• 　　V4Lのラッパ＋インターフェース
• 全体構成
• 　Java
• 　JNI
• 　上はJava
• 　縦は空間
• 　アプリはJavaからJNIへ行ってSystemServerとかの空間へ行く
• 　SufaceFlingerでカメラ映像が合成されて吐き出される
• V4L2
• 　歴史ある
• 　QBUFという構造を使う
• 　　ストリーミングスタート
• 　　上位と関係なくストリーミングする
• Camera Hardware
• 　ioctlでデキューする
• 　GrubRawFrame
• 　mRawHeapに上がってくる
• 　YUV
• 　　動画にYUVで使う
• 　　静止画としてJPEGで使う
• 　　プレビュー用にRGBで使う
• 　mPreviewHeap
• 　mRecord***
• 　Camera Serviceで撮ってきたのとSystemServerとで撮ってきた画像を共有している
• 　SkiaもSystemServerと共有している
• 　MediaPlayerServiceのバッファにもYUVが共有されている。POSTしてる。
• 　今日のはサンプル用の実装になってる。
• 　　HTCはもっと賢い実装をしている
• 　Camera Hardwareの機能はDSP化できる
• 上級者向けの課題
• 　HTC商用機のLinuxカーネル
• 　　HTC developer
• 　　http://developer.htc.com/
• 　DSPを利用した画像処理
• 　　ドライバの構成
• 　　カーネルインターフェース
• 　　メールボックスを利用したDSPからRPC

frameworks/base/camera/libcameraservice/

hardware/msm7k/libcamera

• Javascript上でPC Linuxが動く
• カーネルとかファイルシステムはキャッシュされている
• １１秒ほどで起動
• gccがない
• tccでコンパイルする
• hello.cはHello World
• ファイルのアップロード方法がわからない
• 　クリップボードでアップロード出来るらしい
• emacsが動く
• viも動く
• Androidでも動く
• 　Froyo以降のブラウザが必要
• 　N１（2.3.4)で動く
• 　旧ペリアは無理(2.1)
• Androidのエミュレータでも動かす
• 　１０分くらいで立ち上がるｗ
• qemuの作者
• 　ファブリース・ベラール
• ソースをのぞく
• 　トップページのHTMLソースをのぞく
• 　function test_typed_arrays()が本体
• 　window.Uint8Array〜を試している
• 　　レジスタのアクセスを試す
• 　cpux86_ta.js
• 　　caseがいっぱい出てくる
• 　　ソースのほとんどがswitch文
• 　　最初のほうはレジスタ宣言
• 　　仮想メモリもサポートしている
• 　　フィジカルメモリはArrayBuffer
• 　　どの回路モジュールに処理を渡すかのcase文がいっぱい
• 　　フローティングポイントは未サポート
• 　　switch文の山だから最適化はされていない
• 　　　x86の仕様をそのままソースにした形
• 　　プロセスはinitとシェルだけ
• 　　メモリは１４MB
• 　　　ソースは１６MB
• 　　/binとか/usr/sbinにはいろいろコマンド入ってる
• 　　wget入ってるけどカーネルがネットワーク未対応ｗ
• 　　コマンドはbusybox
• 　　proc/cpuinfo
• 　　model name : pentium MMX
• 　　bogomips : 20.22
• 　　fpu : no
• 　term.js
• 　　ターミナルエミュレータ
• 　　ぐじゃぐじゃでよくわからない
• カスタマイズ方法
• 　jslinux.jsをいじる
• 　params.mem_size　メモリサイズ
• 　pc.load_binary()　
• 　vmlinux86.bin カーネル
• 　root.bin ルートファイルシステム
• 　linuxstart.bin ブートローダー
• javascriptの配列の最大値はいくつ？
• デバイスドライバはほとんど入っていない
• 　HDD、シリアルデバイスですら未対応
• Androidを動かす場合はカーネルがデブる
• 質疑
• 　JSの整形方法
• 　　emacsのマクロとかだけ。ツールは使っていない。
• 　　；で改行、中括弧
• 　　てつこばさんの発表の前半で出来上がる
• 　jslinuxを起動したchromeタブのメモリサイズ
• 　　５０MB
• 　　思ったよりも食っていない

• 自己紹介＆告知
• 6/11(土曜）
• もくもく会
• 関内の平沼レストハウス
• Gerritはgitを基本としたレビューツール
• gerrit2とは？
• 　Google謹製のソースコードレビューシステム
• 　特徴
• 　　マルチレポジトリ
• 　　ワークフロー込み
• 　　様々な認証サポート
• 　　　Apacheのサポートしている認証/Open ID / LDAPなどなど
• 　　簡単なセットアップ
• 　　　java -jar gerrit.war initだけでGit Server / SSH Server / HTTP Server同梱
• 　　EgitにGerritの文字がある
• 開発者・レビューする人・保守する人
• 　repoで落としたりアップしたりする
• 特徴
• 　権限のある全てのプロジェクト、ブランチのコミットがおえる
• 　ポイント制
• 　　レビュワーにポイントもらってく。
• 　　Verifierに最終決定権がある。採用するかを決められる
• repo
• 　mydroid/repoを読む
• 　Defaults.xml
• 　　基本的にこれの内容にしたがってシンクする
• 　Manifests/
• 　　Default.xml
• 　　3.0-base.xml 多分まだGPL部分のコミット？
• 　　3.1-base.xml 同上
• 　Projexts/
• 質疑
• 　repoコマンドを使いこなすための資料はなにかある？
• 　　androidのやつ（ソース。アンドロイド。コム）

• 発表内容
イベントの資料を元に説明を行った。
• トゥギャリ内容
• CE Linux Forum: Consumer Electronics Linux 最近 Linux Forumとくっついた。予算が増えた。
• 次回のジャンボリーは9/30
• 「AndroidのfastbootのプロトコルがPandaボードなどTIのu-bootに入ってる。メインラインに。」
• Linaroは、パワマネとグラフィックがオプティマイズの初期ターゲットですね。
• MeeGoとかにもAndroidが載るという話の認識でよいのかな？ それともAndroidMarketに対応するという話
• 「StackOverflow: 技術的なQ&Aサイト。最近活発。」
• 恐竜生成いわく「ABSよりyapfの方が濃い。」

忘れられていた懇親会記録。何事もなく訪れた「焼き物あり」の奇跡。

まさかの中華街のお店で出てきたカレーの味は如何に！

というわけで、PF部メンは中華街の例のお店に３回目のチャレンジをしてきました。

え？カレーの味？いやぁ、おいしかったです。

P.S.

懇親会記録はその日のうちにつけないとだめだね・・・・勢い的に。