この記事では、Snapdragon 801 デバイスが Android Nougat を搭載していない理由について真実を探ります。 チップセット メーカーからベンダーまで、問題は数多くあります。
Android 7.0 の Vulkan または OpenGL ES 3.1 要件を反映するように更新されました。
最近、バージョン アップデート、ベンダーとチップセット メーカー間のやり取り、これが今後のデバイスにとって何を意味するかについて書かれた記事がたくさんあります。 なぜ今週この値が上がるようになったのでしょうか？
さて、由緒ある Nexus 5 が Android 7.0 (Nougat) へのアップデートを受け取らないことを考えると、今週明らかになり、クアルコムはそれが行われないと発表しました。 7.0 では MSM8974 (一般的には Snapdragon 801 として知られています) のサポートを提供します。 この記事は XDA Recognized との協力により書かれました 開発者 マルハナバチ。
この話題はさまざまなニュースサイトでかなりの関心を集めていますが、 多くの人は舞台裏で実際に何が起こっているかの微妙なニュアンスを見逃していますs. この記事では、OEM と協力して公式ファームウェア アップデートを行った経験をもとに、ソフトウェア アップデートの仕組みについてもう少し詳しく説明します。 舞台裏で何が起こっているのか (そしてその理由)、そしてなぜ最終的にあなたの携帯電話に最新のソフトウェアがインストールされないのかを説明します。
Android ファームウェア アップデートの最初のステップは、アップストリーム アップデートです。 これは Google 内部で取り組んでいることです。 「オープン ワークフロー」とは対照的に、Android はクローズド ワークフローを使用して開発されており、毎年、新しいリリースがリリースされるたびにソース コードが壁を越えて投げられます。 当初 Google は、これは最新バージョンを実行している人々による断片化を防ぐためであると述べていました 初期の頃は物事が急速に進化していましたが、このポリシーは維持されているようです 場所。
ある時点、通常はアップデートの一般発表の前に (ただし、最近のパブリック ベータ版の導入により、これらのタイムスケールは変化しています)、
アップストリーム AOSP リポジトリには、限られた数のデバイスのみのデバイス サポートが含まれています。 これらは通常、Nexus デバイスです。 ただし、その理由はすぐに明らかになりますが、Google がこれらのデバイスを完全にハードウェア制御できないことに注意することが重要です。 デバイスは OEM によって製造され、その OEM はチップセット メーカーからシステム オン チップ (SoC) を購入します。
ソース コードがリリースされると、OEM のファームウェア チームは (比喩的に) 静観して姿勢を変えるでしょう。 メインの Android ソース ツリーには、デバイスの出荷に使用される無数のチップセットに対するハードウェア サポートがありません。 たとえば、Qualcomm チップセットは AOSP 内でサポートされていない可能性があります。 あなたの Exynos は間違いなくそうではありません。 メディアテックかハイシリコンか？ 忘れて！
BSP には、Android を実行するために必要なドライバーとハードウェア抽象化レイヤー (HAL) が含まれています。
今必要なのは、 ボードサポートパッケージ (BSP). これは、チップセット メーカーから OEM に提供される、独自コンポーネントの超機密パッケージです。 BSP には、OEM が Android を構築できるようにするために必要なソース コードと、デバイスに必要なドライバーが含まれています。
ここで、Qualcomm のような OEM は、OEM パートナーを必ずしも完全に信頼しているわけではないことは注目に値します。BSP は、「知る必要がある」ベースで利用可能になっています。 OEM は通常、デバイスの極秘部分 (ベースバンドで実行されるソフトウェアなど) のソース コードにアクセスできません。 この部分をクローズすると、近くに示されているように、潜在的な問題も確かにあります。 豊富な そして 繰り返しの ASN.1 脆弱性の解析.
BSP には、デバイス上で Android を実行するために必要なドライバーとハードウェア抽象化レイヤー (HAL) が含まれています。 AOSP には、オペレーティング システムがドライバーに何を実装するかを定義する一連の HAL が含まれています。 ばかばかしいほど単純化された (デモンストレーションの目的で作られた) 例を使用するために、携帯電話の懐中電灯を想像してみましょう。
HAL の例 - 懐中電灯
あなたのデバイスの背面に懐中電灯が付いていると想像してみましょう (Nexus 7 2013 をお持ちの場合は、他の人よりももう少し想像する必要があります -- ごめんなさい!)。 これはドライバーによって制御されます。 非常に単純な例として、v1 HAL が、単一のパラメーター (ライトの状態) を受け取る「setLED」という関数を 1 つ持つ必要があると指示したとします。 これはブール値 (true または false) です。 C では、これは次のようになります。
void setLED(bool ledState) {
// here is the actual code to turn on or off the LED, based on ledState
}
この関数は BSP ソース コード内で定義されます。 BSP は、ROM の構築中に OEM によってコンパイルされ、デバイスのベンダー パーティションまたは領域上の独自の「.so」ライブラリの 1 つになります。 これにより、OEM はデバイスの動作の特定の部分を秘密に保つことができます。 ここでは、LED のオンとオフを切り替える方法を他の人に見せないようにする必要があると仮定します。
ここで、Google が Android の将来のバージョンで HAL の更新バージョンをリリースすると想像してください。 彼らは現在、LED を単にオンまたはオフにするのではなく、LED の明るさを更新できるようにするとよいと判断しました。 おそらくこれはアダプティブ フラッシュのためでしょうか、それとも単に HAL アップデートを強制してチップセット メーカーのビジネスを維持するためなのでしょうか? それについては読者の皆さんにご自身の意見を述べていただきたいと思います。 一部の HAL アップデートには明確なメリットがあります (新しいカメラ HAL が RAW 撮影などを公開するなど) が、その他のアップデートは目的がやや明確ではありません。
明るさ用のこの新しい (架空の) HAL を使用して、Google が setLED という関数を再度公開する必要があると言ったとします。ただし、今回は明るさ用の整数が渡されます。 ここで、0 はオフになり、255 はフルオンになります。
あなたが OEM であれば、LED を点灯させるための超秘密コードをこの新しい機能に組み込むことができます。 パルス幅変調を使用して、数値に基づいて LED の明るさを調整することもできます。 ここで関数を次のように変更します。
void setLED(uint8_t ledBrightness) {
// some super-secret and ultra-confidential proprietary way to set LED brightness
}
だから何？ さて、この新しいバージョンの Android は既存の「BLOB」と互換性がありません。 Android OS は新しい関数定義を期待しており、LED を設定する方法を探すときに古い関数定義を「見つける」ことができないため、OEM はこれらの新しい BLOB を使用する必要があります。
ここで、短い休憩を取って、カスタム ROM (ソースから構築された) がどのように管理されるかを見てみましょう。 それは、あなた方の中の抜け目ない人たちが今、画面に向かって叫んでいることでしょう - 結局のところ、私たちは XDA であり、 HTC HD2、世界で最も長持ちする電話... (念のために言っておきますが、あそこの狂った天才たちは走っています) 最近の HD2 上の Android 6.0! 2009 年に Windows Mobile 6.5 を搭載して出荷された携帯電話としては悪くありません)
ここではさまざまなアプローチが取られています。開発者が ROM 内をハッキングして、古い関数定義を使用するように OS に指示する場合もあります。 これは少し面倒で、維持するために多くの変更が必要です。 もう 1 つのアプローチは、OEM バイナリを「シム」することです。
「シム」アプローチは、期待される関数定義を含む小さな新しいライブラリを自分で書いて構築することです。この例では、明るさの整数をサポートします。 次に、シム内で、古い HAL の要件を満たすようにこれが変換されます。 したがって、この例では、128 を超える明るさを要求すると LED がオンになり、それ以下の明るさを要求すると LED がオフになると言えるでしょう。 または、ゼロ以外の値がオンになると言うのもできます。 それは開発者次第です。 彼らは shim をコンパイルし、Android がネイティブの代わりにそれを使用できるようにします。 次に、シムは OEM BLOB を呼び出します。
古い HAL しか持っていない場合でも、すばやく「adb Push」を押して再起動すると、シムが動作し、架空の LED を制御できるようになります。
問題は、これが明らかに不完全なプロセスであることです。 このデバイスでは、完全にオンまたは完全にオフになる、かなりひどいフラッシュが表示されます。 これは理想的ではありません。OS は非常に穏やかな光を出していると認識していますが、実際の LED は人工太陽のコンテストに出場しており、ユーザーの目をくらませようとしていると認識されています。 しかし、人生は完璧ではありません。古い携帯電話に LED が点灯しました。
(はい、これが、XDA ユーザーと開発者が移植の腕前というクレイジーで非常識な偉業を管理するときに、癖やバグが発生する理由の 1 つです。 つまり、一体、 ギャラクシーS II 一見使えそうなものを持ち歩いています Android 6.0 ROM になりました. 昨年発売された多くの携帯電話にはまだ 6.0 が搭載されていません!)
OEM の視点に戻りましょう。 残念なことに、ほとんどの OEM は、現時点よりも少なくとも 1 台先の電話機をすでに開発しています。 彼らの焦点は、次に販売しようとしている携帯電話にあります。彼らは販売するデバイスでのみ利益を得ているため、実際には彼らを責めることはできません。 1 ～ 2 年前に販売したデバイスからは利益が得られないため、存続するには新しいデバイスをリリースし続ける必要があります。 これが、HTC と Blackberry が苦境に陥っている理由の 1 つです。古い Blackberry Curve で新しいデバイスが販売されないのですから、どれだけの幹部がその古い Blackberry Curve に死のうとしているかは問題ではありません。
OEM が BSP を取得しない場合、ビルドをハッキングするという XDA アプローチを採用することはありません。 なぜ？ 良い、 顧客のためにこのファームウェアをサポートする必要がある. もし彼らが中途半端なファームウェアをリリースしたら、ユーザーはそれを嫌い、暴言を吐き、激怒し、何日もサポートラインが鳴り続けるでしょう。
OEM は通信事業者とも戦う必要がある、少なくとも非ヨーロッパ市場では。 通信事業者は、顧客がソフトウェアのアップデートで問題を抱えてしまうのを望んでいません。 実際、通信事業者はソフトウェア アップデートをリリースしたくないことがよくあります。
これを理解するには、あなたの大叔母のアリスを想像してください。 彼女は、都合の悪い時間にあなたに電話して、「コンピューターに関すること」について助けを求めてくる人です。 次に、「スタート メニュー」をクリックする方法を説明し、それを「左下隅の大きな旗」として識別する必要があり、混乱に遭遇します。 約 45 分後 (そして非常にイライラしながら)、アリスおばさんがスタート メニューを画面の右側の端にドラッグし、単にドラッグして元に戻す必要があったことが判明しました。 はい、マウスの左ボタンを使用します。
さて、あなたには千人のアリスおばさんがいると想像してみてください。」 彼らは皆、携帯電話でキャンディ クラッシュが見つからず、ハッカーによって携帯電話からキャンディ クラッシュが削除されたのではないかと心配して、カスタマー サポートに電話をかけています。 ああ、アイコンの見た目が少し変わっています。おそらくハッカーはまだ携帯電話の中にいますか?
確かに、これはちょっとした気楽なユーモアのつもりですが、人々がキャリアにサポートを求める理由を体験するまでは、彼らが抱えている問題を信じられないでしょう。 電話機の動作方法や状況を変更するソフトウェア アップデートでは、サポートに多大なコストがかかります。 少なくとも、サポート スタッフの再トレーニングが必要です (残念なことに、サポート スタッフのほとんどは熱心な XDA 読者ではないためです)。
OEM が BSP を取得すると、ROM を移植し、すべての変更を ROM に適用します。 彼らはブロートウェアを積み上げ、ティーンエイジャー向けのアニメでより家庭的に見えるような恐ろしい漫画風のスキンを追加します。 それから彼らはそれをテストします。
たくさん。
携帯電話はあらゆる種類の要件に準拠する必要があります。 モバイル ネットワークは、ユーザー機器 (いわゆる電話) が正しく動作することを信頼するように設計されています。 これは、デバイスを承認するには多くのテストが必要であることを意味します。 ソフトウェアの更新には動作が変わるリスクがあるため、再度テストする必要があります。 このため、ファームウェアがテスト要件に準拠していることを確認する、外部テスト サービスからの今後の Sony ソフトウェア アップデートに関する情報がよく表示されます。
今... 1 つまたは 2 つのアップデートの後 (場合によっては何もしない場合) はどうなりますか? SoC メーカーは OEM に更新された BSP を提供しません. 結局のところ、SoC メーカーはこれで多くの利益を得ることはできません。 携帯電話が販売されてから、OEM はそれ以上の利益を得ていません。 現時点では、お使いの携帯電話にはこれ以上のメジャー バージョン アップデートはありません。
OEM が配信を希望する BSP の数を減らすことは、現在の BSP のみが必要で、メジャー バージョンを配信する予定がない場合、コストを節約するための優れた方法です。 増加すると、最初の SoC の購入とライセンスの費用が節約されますが、将来的には、なぜ XDA を入手しなかったのかと疑問に思って怒っている数人のオタクが犠牲になることになります。 アップデート。
アップデートは複雑です。 その連鎖にはさまざまな人が関わっています。 このようなことは、OEM が Android のアップデートの現在の不十分で悲惨な状態を免責するものではありません。 それにもかかわらず、ここには実際の課題がいくつかあります。
多くの OEM は過剰な約束をした責任があり、 私たちが今連想している避けられない過小納品. 悲しい現実として、ほとんどの OEM にとって、ソフトウェア アップデートはなくても済む迷惑な存在です。
モバイル分野はほとんどがフィーチャーフォンの考え方に囚われています。 つまり、デバイスが更新をまったく取得しない場合です。 一度テストして出荷すれば、後は決して振り返る必要はありません。 最新のスマートフォンにはセキュリティの問題があり、何百もの外部ライブラリを備えた完全な汎用オペレーティング システムを実行することは非常に複雑なので、それはもはや選択肢ではありません。 あるいは少なくともそれは すべきではありません なれ。 Google は、少なくとも既存のリリースのセキュリティ情報とパッチを公開することで、この問題を修正するためにいくつかの措置を講じました。 Android のバージョン (ごく最近まで、セキュリティ アップデートを入手するには、Android OS の新しいメジャー バージョンを介するしか方法がなかったのを思い出してください!)
しかし、残念ながら、これだけでは十分ではありません。 Google がアップデートをリリースし続けているにもかかわらず、デバイスのセキュリティは依然として SoC メーカーに依存しています。SoC メーカーは非常に怯えているためです。 誰かが LED をいくつか点灯させたり、スピーカーから音を出したりする方法を発見し、大量のバイナリ BLOB を デバイス。 これらの BLOB には、非常に安全でないコードが含まれており (これが誇張だと思われる場合は、過去の Google セキュリティ情報を見てください!)、更新する必要があります。 つまり、更新された BSP が必要です。
デスクトップ コンピューター (ひいてはラップトップ) は、モバイル デバイスとはアーキテクチャがまったく異なります。 あなたの携帯電話やタブレットは事実上、かなり独占的なシリコンの塊であり、善意はあるものの、良いものを作るのに十分な時間がない一部の人々によって急いで設計されたものです。 市場の動きが非常に速いため、マーケティングが新製品の発売を要求するペースにほとんど追いつくことができません。
これは、ショートカットが使用されることを意味します。お使いの携帯電話がメインライン Linux カーネルでサポートされていないことがわかり、電話ごとに異なる起動方法があることがわかります。 ただし、ラップトップまたはデスクトップでは、ベンダーはいくつかの標準的なブート方法に落ち着きました。以前は BIOS を使用した MBR (マスター ブート レコード) でしたが、現在は UEFI です。 この標準化により、各デバイスで同じソフトウェアを実行できるようになります。
最近、特にソニーの支援プログラムや 統合カーネル、各デバイスに膨大な数の新しいベンダー固有のハッキングが導入されているため、ほとんどの携帯電話でメインライン カーネルを実行することは現実的ではありません。
ヘッドフォンジャックの配線を逆に接続していませんか? ドライバーをハックするだけです。 製品設計でそれを修正する時間はありません。
製造チームは、生産バッチ 1 でカメラ モジュールを逆さまに取り付けましたか? ハックを導入して内部バージョン コードをチェックし、バージョン 1 であればビデオを反転させます。
このようなハックは当面の問題を解決しますが、進行中の奇妙で製品固有の変更の表面を削っただけです。 商業上の決定により、同じ携帯電話の異なるリビジョンにはまったく異なるチップが搭載されていることもあります。 これらは、ドライバーのハッキングや、携帯電話を動作させて来週出荷できるようにするという当時にしか意味がなかった奇妙な決定につながります。
UEFI を使用してブートする 64 ビット ARM チップのメインライン サポートに向けた作業が進行中ですが、これまでのところ ARM デバイスをブートするためのより標準化された方法に向けた明確な動きはない. これは悲しいことです。なぜなら、携帯電話は寿命が終わるずっと前に捨てられ続けることを意味するからです。 技術的負債と従業員の負担を維持するにはあまりにも費用がかかりすぎるため、労働生活は困難です。 ソフトウェア。
しかしその一方で、OEM がデバイスの販売だけで利益を得るのであれば、人々が新しい携帯電話を買い続けられるようにする必要はないのでしょうか? オープン PC プラットフォームと標準を使用する 30 年間の勢いとレガシー ソフトウェアがすでに世に出ていなかったら、PC 市場はこのモデルに移行するでしょうか?
これはクアルコムの内部情報がなければ難しい質問ですが、残念ながら現時点では情報がありません。 ただし、7.0 Android ドライバー API と CTS 要件からいくつかの情報を引き出すことができます。 CTS 要件は、Google が特定のファームウェアを実行するデバイスに何を期待するかを指定します。 これらの要件を強制するために使用される「大きなハンマー」は、独自の Google Play Services バンドルを使用するための Google のライセンスです。 遵守しない場合、デバイスに Google Apps を配布することはできません. 一方、一部の人にとっては、これは 利点として見られるかもしれない、これは明らかにユーザーがデバイスに求めたり期待したりするものではありません。
Android 7.0 では、HAL やドライバー (前述のとおり) への変更による追加はあまり行われていないため、特にそこから非互換性が生じる可能性は低いです。 しかし、問題を引き起こす可能性がより高いのは、 Vulkan グラフィックス API または GLES 3.1 のいずれかの新しい要件、 CTS を通過するために使用できるようにする必要があります。
現在、MSM8974 を含め、多くのシステムオンチップ (SoC) のグラフィックス プロセッサでは Vulkan がサポートされていません。 ここで、Android 7.0 との互換性の問題が発生する可能性が最も高くなります。 ただし、繰り返しになりますが、クアルコムの内部情報とその将来の計画がなければ、限定せずに決定的な声明を与えることは困難です。 ただし、現時点では、これはクアルコムがサポートを終了する「単純な」ケースである可能性が高いと考えられます。 (彼らの目には) 老朽化した MSM8974 チップセットがあり、そのプラットフォームでは 7.0 用の BSP (ボード サポート パッケージ) が提供されていません。 もしそうなら、OEM はほぼ確実にそのデバイスに 7.0 を出荷しないことを意味します。OEM は、自社の GPU および GPU ソースに対する Vulkan または GLE 3.1 サポートを何らかの方法で見つける必要があるでしょう。 コードは、モバイル スタックのばかばかしいほど厳重に保護されている部分の 1 つです (特別な理由はありませんが、AMD、デスクトップ上で独自の AMDGPU ドライバーをオープンソース化する、を参照)。 Linux)。 ただし、悲しいことに、Vulkan およびアクセラレータ (GLES) グラフィックスは一般に、単純な LED よりも少し複雑であるため、これは互換性を導入するシムの対象ではありません。
7.0 がリリースされてからそれほど時間が経っていないため、他のチップセット (AOSP 自体内の少数のチップセットを除く) が残る可能性があります。 6.0 では、ハードウェアとドライバーの問題 (BSP が更新されていない)、または Vulkan または GLES 3.1 に関する SoC ベンダーのサポートが不足しているため、遅れています。 API。 現時点では、Snapdragon 800 も 801 もこれらのいずれかをサポートしていません。
最善の策はこのスペースを観察することです - XDA の開発者は、Google から公式 7.0 サポートを受けていないデバイスの多くについて、7.0 への非公式移植ですでに順調に進んでいます。 ただし、これらには Vulkan または GLES 3.1 のサポートがありません。おそらく Android 上のゲームの開発者はサポートし始めるでしょう。 多くのユーザーが Vulkan または GLES 3.1 なしでカスタム ROM を実行し始めると、断片化によるフラストレーションが発生します。 サポート？
Apple は、自社の iPhone 製品ラインを最新の iOS バージョンで約 5 年間サポートする傾向があります。iPhone 4s は 2011 年 10 月に発売され、iOS 9 まで最新の状態に保たれています。 ただし、今後の iOS 10 アップデートは提供されないため、iOS 10 が 10 月頃にリリースされると仮定すると、携帯電話の有効寿命は 5 年になります。 Apple が常にグラフィックス API サポートをバックポートしているわけではないことは注目に値します。iPhone 4s と iPhone 5 はバックポートしません。 Apple の Metal グラフィック API を使用します。これは、Android で見られるシナリオとやや似ています。 バルカン。 唯一の違いは、Apple が新しいグラフィックス API を使用せずに古いデバイスをサポートし続けたことです。
どう思いますか？ 携帯電話の寿命を延ばすためにカスタム ROM をフラッシュしますか? 以下のコメントで言ってください。