ドコモさんがAndroidを正式採用しましたね．
しかし、この方式は、機能が比較的単純で価格の安い端末が好まれる海外向けでは、ＯＳを含め別途開発しなければならず、国内端末メーカーの海外進出の大きな障害になっている。国内の携帯電話市場の成長が見込めなくなると、事業撤退する端末メーカーが相次いだのはこのためだ。
このあたりの話を聞くとモジュール間の依存関係によってモジュールの独立性すら失われるジレンマに陥っていると読み取れます．これでは再利用が難しくなるので海外向けに別途開発という話になるのは無理もありません．
"DI 依存関係"でググればいろいろでてきますが，わかりやすそうなリンクを添付．
http://itpro.nikkeibp.co.jp/article/Keyword/20070207/261195/
http://www.stackasterisk.jp/tech/java/seasar201_01.jsp
簡単に述べますと，
あるモジュールAがモジュールBの機能を利用している状況で，Bの仕様変更やバグが発生した場合はAにも影響が発生します．AとBの依存関係が大きいほど深刻な影響が発生します．
ウェブアプリケーションでよくあるのは，アクションのサーブレットコンテナへの依存．これがあるとサーブレット，つまりTomcatなどのアプリケーションサーバが動作する環境以外ではデバッグやテストができないということになります．これも依存関係に関連する話になります．
Java(特にウェブ)では，このモジュール間の依存関係を依存性注入というデザインパターンと，それを簡単に扱うためのフレームワーク(DIコンテナ)，Seasar2やSpringが登場して開発のしやすさが向上してきた経緯があります．
これは組込業界でも例外ではないと思います．聞いた話では，年々，組込機器のソースコードの規模は爆発的に増えているらしく，というか多機能化しているので無理もないと思います．(私の持っているHDDレコーダのRD-X6なんて，機能も多くPCより複雑です．)おまけにローカライズもある，ローカライズといっても言語リソースだけの問題ではなく，上記のように海外向けにはフェリカの機能は外すなども含めてローカライズになりえます．そうなってくるとモジュール間の依存関係の話に必ずなります．
一番はどんな開発言語を使っていてもモジュール間の依存関係を密にしない設計思想，つまり疎結合の思想が大事．
そういう意味では，Androidのモジュール型アーキテクチャは疎結合を実現しやすいはず．また，Eclipseの基盤に使われているOSGiもバンドルというモジュール型のアーキテクチャが採用されています．これもまた疎結合を実現しやすくなります．もっと拡大解釈するとSOAを実現するためのツールとして捉えることができるのではないかと思います．
ここまで組込も複雑化してくると，旧来の開発言語を捨てて，より高級な機能を持った言語やフレームワークが必要で，家電とネットの時代ではインターネットを前提にした開発言語を選択していくべきだと思います．現にAndroidやOSGiなどでは，アプリケーション開発言語としてJava言語を前提してしています．
ソフトウェアが高機能化すると，ハードウェアも高スペックなものが必要なっていくと思いますが，これはあくまで対象とするビジネスに最適化していくための選択と考えれば，必ず費用対効果は出るのではないかと思っています．
そういう意味では，JavaプラットフォームとしてのAndroidには期待しています．
