Exynos デバイスが最高の AOSP サポートを受けられない理由を疑問に思ったことはありますか? イベントの概要をご覧ください。
覚えておいてください、覚えておいてください、メモの最初、ICS のリリースとプロット
スーパーブリックの反逆罪がなぜ忘れ去られるべきなのか私には分かりません
フォーラムの古いメンバーや初期の Samsung デバイスの Android ユーザーは、このことをかすかに覚えているかもしれません。 スーパーブリックの大失敗. スーパーブリックに至るまでの出来事は長く複雑です。 簡潔にするために、TL; 博士の説明によると、Galaxy S2 i9100 と Galaxy Note N7000 のいくつかのキャリア バージョンの ICS アップデートのリークが原因で、 永久レンガ. これは通常のハード ブリックではなく、影響を受けたデバイスは JTAG 経由で復活できず、完全に停止して応答しなくなっていたためです。 スーパーブリックはデバイスの eMMC に影響を及ぼしたため、マザーボードを完全に交換する必要がありました。
一般に「リーク」に付随する免責事項は、このケースでも有効でした。つまり、リークは本質的に「未リリース」のソフトウェアであり、一般の消費に適しているかどうかはわかりません。 ただし、問題を複雑にしているのは、この超強力な ICS カーネルが、Kies および OTA アップデートを通じて利用できる公式リリースとして、実際に Galaxy Note N7000 に導入されたことです。
Superbrick の大失敗と、開発者に対する Samsung の態度によって引き起こされたそれに伴うドラマは、XDA 上級認定開発者としても知られる Andrew Dodd 氏による 13 回の投稿シリーズで取り上げられました。 エントロピー512 彼のGoogle+で。 この投稿シリーズの冒頭をご覧ください ここ. 私たちは 強くお勧めします 読者は少し時間をとって一連の投稿をすべて読んで、完全な文脈認識を収集し、2012 年から 2013 年に起こった状況の重大さを理解してください。
いくつかの重要な点を強調するために、投稿からいくつかの抜粋を (強調を加えて) 示します。
"...明らかに、私をフォローしているほとんどの人は、最近のソーシャルメディアの嵐が、人々のフラストレーションから生じたものであることを知っています。 サードパーティの Android ファームウェア コミュニティ (特に CyanogenMod ユーザーと開発者) は、 サムスン。 「Superbrick」の大失敗、Qualcomm や TI の SoC と比較した Samsung の Exynos4 SoC に関する文書の欠如、その他の問題の羅列リスト - これらすべてが最近になって頭角を現しました。
"...11 月に、Samsung は I9100 用の XWKK5 と I777 用の UCKK6 をリリースしました。 これらのビルドの Bluetooth HID は、ソースでビルドされたカーネルでは機能せず、それらのビルドに関連付けられたバイナリでのみ機能します。 サムスンは、バイナリにソースへの機能変更の明らかな証拠が示されていたにもかかわらず、I9100 用の別のジンジャーブレッド ソース アップデートをリリースすることはありませんでした。 同様に、I777 UCKK6 ソースは、2012 年半ばの不明な時期までリリースされませんでした。私は、良くても I9100 ICS がリリースされた後までリリースされなかったとかなり確信しています。 そうです - Samsung は GPL に違反していました I777 UCKK6 と、XWKK5 (2011 年 11 月) から I9100 ICS が正式にリリースされる (2012 年 3 月) までのすべての I9100 ジンジャーブレッド ビルド - 実際には、 これらのカーネルに対応するジンジャーブレッドソースはリリースされていないため、技術的にはまだ存在しますが、それは実際には問題ではありません もっと..."
"...同じ頃、Samsung は Tab 7.0 Plus と Tab 7.7 を発売しました。どちらも GS2 に搭載されているのと同じ Exynos 4210 SoC をベースにしています...これらのデバイスは Atheros AR6000 シリーズ Wi-Fi チップを使用していました。 興味深いことに、Atheros は、GPL と BSD のデュアル ライセンスに基づいてこれらのデバイスのソースを提供しています。 (Atheros はリファレンス ドライバーのすべてのコンポーネントに対する完全な著作権を保持しているため、これは合法です。) Samsung は、このドライバーの BSD ライセンスを選択しました。 最終的な結果は、Wi-Fi ドライバー ソース (これらのデバイスのソース ドロップには存在しませんでした) を要求された場合、次のようになります。 サムスンは「コードはデュアルライセンス GPL または BSD です。 私たちは [GPL ではなく] BSD を選択します。」" - 親の投稿
"...GT-I9100 の ICS から明らかな結論があるとすれば、それは次のとおりです。 メーカーのスキンが長持ちしない. I9100 ICS ファームウェアを I777 上で実行した後 (主に、交換されたマイク チャンネルをリバース エンジニアリングすることによって) このデバイスは、週末の作業のほとんどを費やしました...)、Touchwizz の利点の多くが元に戻ったことは明らかでした。 ICS。 ファームウェアの一部は「新しい」もので、一部は「レガシー ジンジャーブレッド」であり、絶え間なく途切れるのは不快でした... - 親の投稿
さらに悪いことに... N7000 向けに XXLPY を使用した公式 ICS が開始されました。 私たちはサムスンがリリースされたカーネルにこのような恐ろしいバグを決して入れないと思っていましたが、それは間違いでした...
- 親の投稿
"...サムスンの担当者は、状況を認識しており、それに「熱心に取り組んでいる」ことを最終的に認めました... 最終的に、サムスンの「解決策」が私たちに提示されました。 Chainfire は提案された「解決策」に満足していませんでしたが、私も同様でした... これにはカーネル レベルの保護が含まれておらず、CM の BOARD_SUPPRESS_EMMC_WIPE で既に導入されていたものよりも劣っていました。 さらに彼らは、ソリューションを配布しないよう、そしてソリューションを探しているカーネル開発者をリダイレクトするよう私たちに求めました..."
"...サムスンもブートローダーに関する解決策について議論することをほぼ拒否しました... その理由は、意味不明ですが、この eMMC 欠陥以前のカスタム ファームウェアに起因する保証請求のほぼすべてが、ブートローダーの破損によるものだったということでした... もちろん、これでは意味がありませんので、 私たちは、ブートローダーの破損から回復する方法について話し合いたかったのです。これにより、Samsung の保証コストの大部分が削減されます。. 私たちは、Samsung が Dominik と Adam が必要とする特定の小さなコンポーネントを提供してくれた限り、エンジニアリングとソリューションの導入の大部分を自分たちで行うことを提案していました..."
"...サムスンは1か月間「熱心に働いた」後、私たちの顔に手榴弾を投げつけた
7 月初旬に、I9100 の XXLQ5 がリークされました。 一日のうちに、レンガが積み重なったという報告が多数寄せられた。 それから間もなく、XWLPM が Kies 上で稼働し始めました。 人々もこのビルドで左右にレンガ造りをしていました.
と主張しているにもかかわらず、 熱心に働く この問題に関して、サムスンは代わりに、これまで安全だったデバイスを取り上げ、危険にさらしました...」 - 親の投稿
"...ということで、現時点では 2012 年 11 月中旬ですが、Samsung の欠陥のある eMMC の影響を受けるデバイスは 1 台もカーネル修正を受けていません。 コミュニティの努力により、Samsung の公式カーネルが有効である限り、損傷率は大幅に低下します。 脆弱なため、私には助けが必要な Superbricked ユーザーから数日ごとに PM が届きます。 ヘルプ..." - 親の投稿
"...8 月中旬、私は賢明な判断に反して Note 10.1 (WiFi バージョン - GT-N8013) を購入することにしました。 I9300 と SoC を共有しているので、かなり安全な選択だと思いました...
Wi-Fiドライバーの非機能性と、バックアップされたファイルとのさまざまな文字列比較の両方を通じて確認したところ、 ストック カーネル、N80xx バリアントのリリースされたソースがストック カーネルと一致しなかった (すべてのカーネルが同じ壊れた Wi-Fi を持っていた) ドライバーや情報源に協力していた他の人々も同様の問題について苦情を申し立てました。）、私は次の連絡先に問題を提起しました。 サムスン…
彼らは誰かを追跡しましたが、その人の返答は次のとおりでした。GT-N8013 の UEALGB ビルドは公式ビルドではないため、Samsung にはそのビルドと一致するソースを提供する義務はありません。 はい、そうです - 誰かが実際に 米国で販売されるすべての GT-N8013 ユニットにプレインストールされているファームウェアはリークであると敢えて主張しました. Samsung Mobile 内の誰かが私の連絡先に対してあからさまに嘘をついたのはこれで 3 回目です...」 - 親の投稿
"...それで、その間に、他のもの (多くの例については、この物語の以前の記事を参照してください)、および Superbrick、 Exynos4 のメンテナのほぼ全員が Samsung、特に Samsung に対して疲労の限界に達していました。 エクシノス４．
私は Note 10.1 が最後のデバイスになるだろうと言いましたが、この時点でも疲れきっていたので、いつまで I777 と N7000 を使い続けることになるかわかりませんでした。
他のどのデバイスよりも BLOB が多く、BLOB 内のインターフェイス ブレークが多いデバイスを使用していたため、Cyanogenmod チームの他のメンバーより何か月も遅れることにうんざりしていました。
(Tegra3 デバイスを除きますが、Nexus を使用していない限り、これらのデバイスを避ける必要があることは人々にすでに知られていました。)..." - 親の投稿
"...[BABBQ 2012]の終わり近くに、サムスンの開発者向けプレゼンテーションが行われました。 ここで彼らは、Exynos4 のリファレンス ソース コードとドキュメントの品質を向上させることを約束し、理論上はコミュニティの懸念を軽減しました。 実際のプレゼンテーションの内容はほとんど期待できませんでした - 彼らが発表したほぼすべてのものは、技術的にはすでに存在していましたが、時代遅れであるか単に機能していないため、ほとんど役に立たなかったものでした..." - 親の投稿
これらすべては、サムスンが1年以上にわたって話し合い、約束してきたのと同じように、話したり約束したりしなかったりする新たな事例にすぎません。 開発ボードは携帯電話機よりも先にあるべきであるため、通信事業者のテストに取り組む必要はありません。 ワイヤレス認証、または通常、ハンドセットを妨げることで悪名高いもののいずれか 更新情報。 さらに、彼らの意図したターゲットは開発者であるため、彼らは「最先端」である必要があります。 これは、クアルコムと TI のリファレンス ソースです。これは、携帯電話で見られるものよりも先の、絶対的な最新のものです。 Samsung から得たものは 6 か月以上古いものです - ICS で発売された携帯電話に搭載されていた SoC の ICS 2012 年春にリリースされ、10 月初旬に公式の Jellybean アップデート (通信事業者の承認/無線証明書など) を受け取りました。 2012... しかし、彼らはまだリファレンス ソースとして ICS に取り組んでいます。
- 親の投稿
このシリーズは、要約投稿で終了しました。 ここ. すべてのユーザーが続行する前にこれを読むことをお勧めします。
この記事の出発点は、Exynos デバイスが Qualcomm デバイスと比較して、AOSP ベースの開発が通常不足している理由を説明することでした。 上記で引用した G+ 投稿シリーズでは、Exynos デバイスの保守者が直面する困難を浮き彫りにしました。 この投稿の日付は 2011 年から 2013 年にかけてのものであるため、現在の状況を把握するために、言及された開発者の数人に連絡を取りました。 結局のところ、モバイルの世界では 3 年で多くのことが変わる可能性があります。
Samsung とその AOSP サポートには当てはまらないようです。
Q: Qualcomm デバイスと比較して、Exynos デバイスでは AOSP ROM が完成するまでにこれほど時間がかかるのはなぜですか?
A: XDA 上級認定開発者 コードワークx:
クアルコムは、プラットフォームのすべてのコンポーネントを aosp で動作させるために必要な、常に最新のソース コードをリリースします。 見る ここ.
サムスンは何もしない。
XDA 上級認定開発者 エントロピー512:
"クアルコム CAF OEM リリースとの間のトレーサビリティの点で非常に優れています (Nexus 以外の OEM デバイスで、CAF タグまで簡単に追跡できないものを見たことがありません) コードオーロラ)、コードの品質、更新頻度 インシグナル (「Arndale Octa」用の KitKat はなく、Exynos4 用の ICS 以外に新しいものはありません。) 時代遅れであることに加えて、Samsung Mobile の OEM 間のトレーサビリティはまったくありません。 すべての OEM は CAF までのかなりの量のトレーサビリティを持っています (HTC と Samsung は他のものより若干劣りますが、それでも他のものよりはるかに優れています)。 エクシノス)
待てよ、彼らは最終的に Origen Quad 用に JB をリリースしたのか？ キットカットがほぼ発売されるまでは... そして、彼らがJBと呼んだものは、おそらく彼らにとって無用な災害に近かったでしょう。 ジンジャーブレディ「ICS」
Exynos3 別名 Hummingbird は、Nexus S のおかげでまったく別の話になりましたが、サムスンはそれ以来、Nexus デバイスと他のデバイス間でチップセットを共有しないことを徹底しています。 (Galaxy Nexus は OMAP4 でしたが、その時代のいくつかの例外を除いて他のすべては Exynos4、Nexus 10 と Samsung Chromebook の 2 つが唯一の例外でした) Exynos 5250 デバイスが出荷され、Exynos 54xx は Mali GPU から PowerVR に切り替わり、その他の多くの変更が加えられたため、manta は I9500 では役に立たなくなりました。 等。）"
Q: Exynos 開発の将来はどうなりますか? サムスンは開発者にとってより使いやすいものにするためにどのような措置を講じることができるでしょうか?
A: コードワークx:
未来はない。 あなたが作成したすべての開発者は、ずっと前に exynos デバイスでの動作を停止しました。 彼らのほとんどは、サムスン製デバイス全般の作業を停止しました。
私たちはソースコードを何度も尋ねましたが、何も起こりませんでした。 彼らは単にコミュニティのことを気にしていないだけです。 彼らが気にしているのは $$$ だけです
状況が 3 年以上前とほぼ同じであることは明らかです。 Samsung デバイス、特に Exynos ベースのデバイスは、Touchwiz ベースの例以外の開発コミュニティの成果を紹介する例としては依然として不十分です。 デバイスのすべての開発は、依然として Touchwiz への変更に主に制限されており、カスタム シーンも含まれます。 ROM は、サムスンのクローズド ソース OS の「スキン」にリバースを通じて機能を追加または削除することを中心に展開しています。 エンジニアリング。
これは、Exynos デバイスが AOSP ROM をまったくサポートしていないということではありません。 AOSP Roms は、CM などと同様に、 最終的に これらのデバイスは、多くの低レベルのハッキングと、自由時間をすべてサムスンが壊したものを修正することに費やす勇敢なメンテナーによる極端な努力の末に誕生しました。 それでも、最終結果は通常期待されるような AOSP エクスペリエンスではなく、これについては Samsung を非難しても問題ありません。
スーパーブリックの傷は、サムスンを名乗る壊れた大義に向かって心と魂を結集して取り組んだ人々の心にまだ生々しい。 カスタム ROM 開発とサードパーティ ROM 開発者のサポートを第一の基準としてデバイスの購入を検討している場合は、Codeworkx が共有する知恵の言葉に従ってください。
そのような企業のデバイスを購入してサポートするのはやめてください。
sony または nexus デバイスを手に取り、高品質の aosp rom、優れたコミュニティサポートを得て、ただ幸せになってください。