遠回り気味にいろいろ試してみました。
- kernel configに下記を追加
- smack対応
- IPv6対応
- 起動スクリプト修正
- ・・・詳細は忘却のかなた・・・
今の環境だと、S44boot-ospはたぶん成功していて、indicatorの初期化に失敗している模様。
/etc/rc.d/rc3.d/S44boot-osp start Starting OSP app-service ... test successs ret = 0 /etc/rc.d/rc3.d/S44indicator start Application initialization failure for .
試しにTizen gitを”Application initialization failure”でgrepしてみても引っかかりません。indicatorのソースはここにあるのですが、アプリケーションフレームワークの構成はややこしい感じです。。
フレームワークの構成は、WebUIのパスと、EFLをダイレクトに利用するものと、OSPレイヤーを経由するものに分かれる様です。実装上は(パッと見は)2つで、EFLとOSPで異なっていて、WebUIはEFLアプリとして実装されているように見えます。
そういう意味ではporting guideの構成図(↑の画像)は厳密には違う気がして、どちらかというと"Graphic & UI"の図↓が正しいんじゃないかと思われます。
EFLフレームワークを利用した、indicatorのmainはdaemon/indicator_ui.cにあって
int main(int argc, char *argv[]) { struct appdata ad; app_event_callback_s event_callback; int heyfd = heynoti_init(); if (heyfd < 0) { ERR("Failed to heynoti_init[%d]", heyfd); } int ret = heynoti_subscribe(heyfd, "power_off_start", _heynoti_event_power_off, NULL); if (ret < 0) { ERR("Failed to heynoti_subscribe[%d]", ret); } ret = heynoti_attach_handler(heyfd); if (ret < 0) { ERR("Failed to heynoti_attach_handler[%d]", ret); } event_callback.create = app_create; event_callback.terminate = app_terminate; event_callback.pause = app_pause; event_callback.resume = app_resume; event_callback.service = app_service; event_callback.low_memory = NULL; event_callback.low_battery = _indicator_low_bat_cb; event_callback.device_orientation = NULL; event_callback.language_changed = _indicator_lang_changed_cb; event_callback.region_format_changed = _indicator_region_changed_cb; memset(&ad, 0x0, sizeof(struct appdata)); return app_efl_main(&argc, &argv, &event_callback, &ad); }
EFL用のcallbackを登録してap_efl_mainでEFLに渡してアプリとして起動する、、、と勝手に思いました。OSPは発想が根本的に異なっていて、
アプリケーションクラスをTizenクラスのなんちゃらを継承して定義して
class CalculatorApp : public Tizen::App::UiApp , public Tizen::System::IScreenEventListener
apps/osp/Calculatorを見てみるとmain相当の関数は
int OspMain(int argc, char *pArgv[]) { result r = E_SUCCESS; AppLog("Application started."); ArrayList* pArgs = new (std::nothrow) ArrayList(); pArgs->Construct(); for (int i = 0; i < argc; i++) { pArgs->Add(*(new (std::nothrow) String(pArgv[i]))); } start_profile(); r = Tizen::App::UiApp::Execute(CalculatorApp::CreateInstance, pArgs); if (IsFailed(r)) { AppLogException("Application execution failed-[%s].", GetErrorMessage(r)); r &= 0x0000FFFF; } end_profile(); pArgs->RemoveAll(true); delete pArgs; AppLog("Application finished."); return static_cast<int>(r); }
多分Tizen::App::UiAppクラスでEFL用に整形してさらにcallbackするんだと思いますが、いやはや、これはウザい。*1
2.0 ReleaseのTizenだと、EFLのcoreと呼ばれるアプリはまだシステムのコア部分の大半を占めていて
app-selector charging-animation libslp-alarm minicontrol print-service tickernoti ug-setting-gallery-efl wrt-setting boot-animation clock libslp-memo mobileprint pwlock ug-bluetooth-efl ug-setting-manage-applications-efl bt-syspopup draglock libug-worldclock-efl music-player quickpanel ug-camera-efl ug-wifi-direct calculator email lockscreen my-account sat-ui ug-image-viewer-efl ug-wifi-efl calendar gallery memo myfiles settings ug-memo-efl usb-manager call gnome-common menu-daemon net-popup smartsearch ug-mobile-ap usb-syspopup call-setting image-viewer menu-screen notification starter ug-myfile-efl video-player camera indicator-win message-app phone-contacts taskmanager ug-nfc-efl volume-app
OSPレイヤーのアプリは本当に電卓とか時計とか上位のアプリになっている様です、ね。。
Calculator CalendarService Clock Email Home Internet Memo MusicPlayer Phone VideoPlayer Calendar Camera Contacts Gallery ImageViewer Lock Messages MyFiles Settings
この構成が保たれるのであれば、OSPはBada互換レイヤーでしか無いように見えるので、別にどうでもいい気がします。。*2
ちなみに、上記以外に通信モジュール系に通信系アプリ用としてconnectivity/bluetooth-share-ui(今はbluetoothだけ。Xbeeとか対応させるならココに置くもの?)と、web/browser、web/download-manager(2.0alphaまではアプリだったはず)が分けられているようです。
結局indicatorのエラーを誰が吐いてるのかは未だわかりません。boot時のアニメーションも単なるpngを連続表示*3しているだけのEFLアプリ*4なので、これが動いているという事はEFLアプリを動かす部分が根本的に破綻しているわけではないはずで、indicatorが動かないのはまた別の要因と考えるべきなのですが・・・。うーむ。。。