この記事は Murat Yener による Android Developers Blog の記事 "AGP 7.0: Next major release for the Android Gradle plugin" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

2020 年 12 月 1 日（日本時間12 月 2 日 ）、Android Studio 4.3 の初めての Canary 版がリリースされ、それとともに Android Gradle プラグイン（AGP）バージョン 7.0.0-alpha01 もリリースされました。Gradle プラグインのバージョン番号の付け方は、Android Studio のバージョン番号のスキームから切り離した上で改めて調整したので、番号を一気に 2 つも飛ばしています。このブログ投稿では、この変更の理由について説明するとともに、インキュベーション状態になっている新しい Android Gradle プラグインの API と DSL について、いくつかの重要な変更点を簡単にご紹介します。

新しいバージョン番号のスキーム 

AGP 7.0.0 では、セマンティック バージョニングの考え方を採用しています。つまり、API の互換性がない変更が発生するのは、メジャー バージョンが変更された場合のみです。メジャー バージョンは、Gradle で年に 1 回のメジャー リリースが行われるタイミングで、毎年 1 つずつ上げることを想定しています。

さらに、互換性のない変更が行われる場合は、1 年ほど前から削除される API に @Deprecated を付け、それと同時期に削除される機能に代わる方法を提供することを保証します。これによりデベロッパーには約 1 年の猶予が与えられ、古い API が削除される前に新しい API を使ってプラグインのテストと移行を行えるようになります。

バージョン 5 と 6 を飛ばして直接 AGP 7.0.0 に変わったのは、Gradle のバージョンに合わせるという理由もあります。つまり、AGP 7.x は Gradle 7.x の API で動作するということです。Gradle 8.x でも動作するかもしれませんが、それは保証されていません。AGP が利用する API が 8.x で削除されていないかどうか次第です。

この変更に伴い、AGP のバージョン番号は Android Studio のバージョン番号とは切り離されます。ただし、当面の間、Android Studio と Android Gradle プラグインは同じタイミングでリリースする予定です。

Android Studio と Android Gradle プラグインとの互換性には、変更はありません。一般的なルールとして、AGP の安定版を使うプロジェクトはそれより新しいバージョンの Android Studio で開くことができます。

Java 11 要件

AGP 7.0.0-alpha01 では依然として Java プログラミング言語バージョン 8 を使用できますが、現在、最低限必要な Java プログラミング言語のバージョンを Java 11 に変更する作業を行っています。これは AGP 7.0.0-alpha02 から適用される予定です。この変更については、デベロッパーの皆さんが余裕を持って準備できるように、Canary 版のスケジュールという早い段階で、安定版リリースの何か月も前にお知らせしています。

インキュベーション状態の API と重要な API の変更点

今回の AGP のリリースでは、いくつかの API が変更されます。なお、AGP 4.1 で導入されたたくさんの API はインキュベーション状態としてマークされ、変更の可能性がありました。そして実際、AGP 4.2 で一部の API が変更されました。現在インキュベーション状態になっている API は、先ほど説明したサポート終了サイクルには従いません。

いくつかの重要な API の変更について、概要をまとめました。

• バージョン 4.2 ベータ版では、onVariants、onProperties、onVariantProperties ブロックが削除されます。
  
  
• これらの API は、新しい androidComponents ブロックの beforeVariants および onVariants で置き換えられます。beforeVariants と onVariants を利用すると、省略可能な VariantSelector を使って、コールバックを実行するバリアントの数を減らすことができます。これは、ビルドタイプ、名前、フレーバーのいずれかに基づいて行うことができ、それぞれ withBuildType、withName、withFlavor を使います。onVariants および beforeVariants が受け取るラムダは、AGP が afterEvaluate でバリアントの組み合わせを計算した後に実行されます。onVariants 内のプロパティのネストは削除されます。
  
  
• 同様の API が androidComponents にも追加され、バリアント内にテストをネストする代わりに、UnitTests 用（beforeUnitTest と unitTest）と AndroidTests 用（beforeAndroidTest と androidTest）に別々のブロックが許可されるようになります。
  
  
• 古い方法と新しい方法の両方でバリアントのアクションの登録に使われていた 2 つのクラスは、名前が変更されました。Variant は VariantBuilder になり、beforeVariants で使われます。VariantProperties は Variant になり、新しい onVariants ブロックに渡されます。

いくつかの変更について確認してみましょう。以下のコードは、リリースビルドをターゲットとするサンプルの onVariants ブロックです。onVariants ブロックは beforeVariants に変更され、次の例のバリアント セレクタを使用します。

```
android {
…
//onVariants.withName("release") {
// ...
//}
…
}
androidComponents {
val release = selector().withBuildType(“release”)
beforeVariants(release) { variant ->
...
}
}
```

同様に、onVariantProperties ブロックも onVariants に変更されます。

```
android {
...
//onVariantProperties {
// ...
\
//}
…
}
androidComponents.onVariants { variant ->
   ...
}
```

なお、このカスタマイズは通常はプラグインで行うもので、build.gradle に配置すべき内容ではありません。レシーバのある関数の使用は避けています。これは DSL 構文には適していますが、プラグインのコードには必要ありません。

これらの API は、AGP 7.0.0 で安定版になる予定です。また、すべてのプラグイン作成者は、新しい androidComponents に移行する必要があります。このような変更に対処するのを避けたい方は、プラグインで安定版の API のみ使用し、インキュベーション状態の API は使わないでください。

今回のリリースに含まれるその他の変更点の詳細については、リリースノートをご覧ください。

Java は Oracle および/またはその関連会社の登録商標です。

Reviewed by Takeshi Hagikura - Developer Relations Team and Hidenori Fujii - Google Play Developer Marketing APAC

ユーザーのためにプライバシー プラクティスを簡素化する

ユーザーデータ プライバシー ポリシーのアップデート

• ユーザーデータの利用や転送は、ユーザーの主要な利益のためであり、明示されている拡張機能の目的に従っていることを保証します。
• ユーザーデータの販売は決して許可されないことを繰り返し表明します。Google はユーザーデータを販売せず、拡張機能のデベロッパーも販売してはいけません。
• パーソナライズド広告のためにユーザーデータを使用または転送することを禁じます。
• 信用度やあらゆる形態の融資資格などの評価のためにユーザーデータを使用またはデータ ブローカーやその他の情報転売業者に転送することを禁じます。

デベロッパーが提供するプライバシーの開示

• ユーザーから収集されるデータの性質
• 新しい限定利用ポリシーに従っていることのデベロッパーによる保証

この記事は Jamal Eason による Android Developers Blog の記事 "Announcing Android Studio Arctic Fox & Android Gradle plugin 7.0!" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

2020 年 12 月 1 日（日本時間 12 月 2 日）、Android Studio Arctic Fox（2020.3.1） の初めてのバージョンが Canary チャンネルでリリースされ、それとともに Android Gradle プラグイン（AGP）バージョン 7.0.0-alpha01 もリリースされました。今回のリリースでは、Android Studio と Gradle プラグインのバージョン番号の付け方を調整しています。この変更で、Android Studio のバージョン番号スキームから Gradle プラグインを切り離し、Android Studio のそれぞれのリリースがどの年に行われて、どの IntelliJ バージョンに一致しているかを明らかにします。

新しいバージョン番号スキーム - Android Studio

Android Studio Arctic Fox（2020.3.1）では、Android Studio のベースとなっている IDE である IntelliJ IDEA との整合性を高めるため、年に基づいた採番に移行します。バージョン番号スキームは、年、ベースとなった IntelliJ のバージョン、機能およびパッチレベルという重要な属性を組み込んだものに移行します。この名称変更により、Android Studio で使っている IntelliJ プラットフォームのバージョンがすぐにわかるようになります。さらに、メジャー バージョンごとに正規のコードネームを割り当てます。最初のコードネームは Arctic Fox で、以降はどのバージョンが新しいのかが簡単にわかるように、アルファベット順に進めます。

デベロッパーの皆さまには、最新の機能と品質改善を利用できるように、最新バージョンの Android Studio を使うことをおすすめします。バージョンを簡単に最新に保つことができるように、Android Studio のバージョンと Android Gradle プラグインのバージョンは明確に切り離します。覚えておくべき重要な点は、IDE をアップデートしても、ビルドシステムがアプリをコンパイルしたりパッケージングしたりする方法は何も変わらないことです。逆に、アプリのビルドプロセスの変更や APK / バンドルは、プロジェクトの AGP バージョンによって決まります。したがって、開発サイクルの後半であっても、Android Studio のバージョンは安全にアップデートできます。プロジェクトの AGP バージョンは、Android Studio のバージョンとは異なるタイミングでアップデートできるからです。また、新しいバージョンのシステムでは、安定版リリースの AGP バージョンを使っている限り、個人やチームのアプリ プロジェクトで安定版とプレビュー版の Android Studio を両方同時に実行することがこれまで以上に簡単になります。 

これまでのバージョン番号システムで言えば、今回のリリースは Android Studio 4.3 になります。新しい番号システムでは、Android Studio Arctic Fox（2020.3.1）Canary 1、または単に Arctic Fox となります。

今後、Android Studio のバージョン番号スキームは次のようになります。

• 最初の 2 つの番号グループは、特定の Android Studio リリースが基づいている IntellIj プラットフォームのバージョンを表します。今回のリリースでは、2020.3 になります。
  
  
• 3 つ目の番号グループは、Studio のメジャー バージョンを表します。これは 1 から始まり、メジャー リリースごとに 1 つずつ増えます。
  
  
• 各バージョンを簡単に表せるように、メジャー リリースにコードネームも割り当てます。コードネームは動物の名前に基づくものとし、A から Z の順番に割り当てられます。最初のリリース名は Arctic Fox です。  

新しいバージョン番号スキーム - Android Gradle プラグイン

AGP 7.0.0 では、セマンティック バージョニングの考え方を採用し、AGP に必要な Gradle バージョンと一致させます。 Android Studio と Android Gradle プラグインとの互換性には、変更はありません。AGP の安定版を使うプロジェクトはそれより新しいバージョンの Android Studio で開くことができます。 

近日中には更に、AGP のバージョン番号の考え方と、今回の新しいメジャー リリースである AGP 7.0 の新機能について詳しく説明したブログ記事を公開する予定です。

Android Studio Arctic Fox の新機能

現在は Arctic Fox の機能開発フェーズの初期段階ですが、コードエディタ、アプリ インスペクション ツール、Layout Editor、組み込みエミュレータなど、IDE のさまざまな領域にわたる 200 以上の品質改善とバグの対応を行いました。具体的なバグの修正については、リリースノートをご覧ください。 

Jetpack Compose を使っている方のために、デバイスやエミュレータへの @Preview Composable のデプロイなど、多くの新しいアップデートを行っています。

新しい Layout Validation ツールもお使いください。さまざまな画面サイズ、フォントサイズ、Android Color Correction / Color Blind Mode にレイアウトがどう反応するかを確認できます。この機能には、Layout Editor を使っているときに [Layout Validation] ツール ウィンドウからアクセスできます。 

最後に、MacOS（その他のプラットフォームも近日中に対応予定）で最新の Android プラットフォーム ツールと Android 11 デバイスを使っている方は、Run  ボタンのデバイス選択ダイアログ → [Pair Devices Using Wi-Fi] から、IDE に組み込まれた Wireless ADB 機能を使うことができます。   

Android Studio と Android Gradle プラグインの今回のリリースに含まれるその他の詳しい変更点については、リリースノートをご覧ください。

Reviewed by Takeshi Hagikura - Developer Relations Team and Hidenori Fujii - Google Play Developer Marketing APAC

AMP Packager は、Signed Exchanges を使って AMP を提供することで AMP URL を改善するツールです。2018 年のリリース以来、たくさんのウェブサイトがこのツールを使って Signed Exchanges を導入してきました。サイト運営者に可能な限り最高の AMP コンテンツを作ってもらう取り組みの一環として、本番環境の設定で AMP Packager を簡単にデプロイしてもらえるよう、継続的に改善を続けています。 

先日は、unix シェル スクリプトと Docker コンテナを使って AMP Packager をデプロイするためのガイドを公開しました。これにより、ユーザーのデプロイ作業は軽減されますが、この手順を実行するには、かなりの技術的知識が必要になります。

そこで、この手順をさらに簡素化するため、Google Cloud Marketplace に AMP Packager Google Cloud Click-to-Deploy Installer を新しく公開したことをお知らせします。

スタートガイド

インストール

https://cloud.google.com/marketplace を開き、[MARKETPLACE を試す] をクリックします。

Marketplace で、“AMP Packager” で検索するか、[Kubernetes アプリ] をクリックして項目の一覧から AMP Packager を探します。

設定

項目を見つけたら、クリックしてデプロイ用のインターフェースを開きます。Click-to-deploy は、すべてブラウザで行える手順を提示し、最低限のユーザー操作で、インストールに必要なことをすべて行ってくれます。下の図で、赤いボックスの部分が必須フィールドです。  

既存の Kubernetes クラスタがない場合は、クラスタゾーンを選択して [Create Cluster] をクリックします。[StorageClass] も同様です。既存のストレージクラス（通常は “standard” という名前）を選択するか、独自のストレージクラスを作成します。

• [Domain] は、生成する Signed Exchanges の対象となるドメイン名です。 
• [Country]、[State]、[Locality] および [Organization] フィールドは、Signed Exchange の証明書を生成するために必要な項目です。通常は、DigiCert などの企業が生成します。  これらのフィールドは、証明書の署名リクエストの作成要求に必要です。
• [ACME Account Email Address] と [ACME Directory URL] も、DigiCert などの SXG 証明書プロバイダの証明書生成設定に必要な項目です。 
• [AMP Packager Load Balancer Source Range] についての説明は、こちらにあります。AMP Packager は、この設定で指定した Load Balancer Source Range からのみ参照できる点に注意してください。

すべて入力できたら、フォームの下部にある [Deploy] ボタンをクリックします。次の画面が表示されます。

すべて正常にインストールできたら、次の画面が表示されます。

あとは、リバース プロキシ サーバーを設定して、AMP Packager を外部 IP アドレス / ポートに向ける必要があります。  これにより、AMP Packager が AMP ドキュメントを Signed Exchanges にパッケージできるようになります。詳しくはこちらの手順で説明されています。

既存ツールをデプロイするこの新しい方法によって、Signed Exchanges を使った AMP ドキュメントの作成が大幅に簡易化され、技術者以外のユーザーでも使えるようになることを期待しています。 ACME 自動証明書更新サポートと合わせて利用すれば、導入後のメンテナンスの難易度も下がります。

投稿者: Allan Banaag（AMP Project、ソフトウェア エンジニア）

この記事は The AMP Blog の記事 "No code required: Build a fast, world-class WordPress site" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

編集者のメモ: 以下のゲスト投稿は、Jetpack のリード アーキテクト、Dan Walmsley 氏による投稿です。元の記事は、 Jetpack ブログに投稿されました。

私たちは、今まで以上にオンラインで時間を使っています。ビジネスを立ち上げようとしている方にも、創造性を発揮しようとしている方にも、高速で美しく、最高のアイデアを優雅に表現できるウェブサイトは欠かせません。また、検索エンジンはこれまで以上にパフォーマンスを重視しているので、遅いウェブサイトでは最適化したはずの SEO が大きく損なわれる可能性があります。

この記事では、Jetpack と公式 AMP for WordPress プラグインという 2 つのプラグインだけを組み合わせて、ワールドクラスのパフォーマンスと SEO を実現する方法について説明します。準備はよろしいでしょうか。早速始めましょう！

プラグインの難題

WordPress には 55,000 個以上のプラグインがあり、さまざまな機能を実現しています。しかし、適切なプラグインを探すのが難しい場合もあります。プラグインを選べたとしても、すべてを高速に動作させることには大きな困難が伴います。それぞれのプラグインによってさまざまなファイルがページに追加され、サイトが遅くなっていきます。 

プラグインやテーマ自体を編集する以外に選択肢はない場合も珍しくありません。そのため、多くのサイト運営者は専門家を雇うことになりますが、その費用はどんどんかさんでいきます。

高速なウェブサイトを作成する最適なツールの 1 つに、AMP があります。AMP はもともと Google が作成し、現在は OpenJS Foundation の一部になっています。AMP は、パフォーマンスを向上させるさまざまなことを自動で行っています。しかし、AMP エコシステムは現在も拡大を続けており、他の WordPress プラグインすべてと互換性があるわけではありません。 

しかし、AMP と組み合わせることで、プログラマーでなくても簡単に使えるソリューションになるプラグインがあったとしたら、どうなるでしょうか。うれしいことに、1 セットのツールだけで、ほぼすべてのウェブサイトに必要なパワーとパフォーマンスをすべて活用できる方法が登場しています。 

AMP + Jetpack: シンプル、パワー、スピード

ここ半年以上にわたり、Google と Jetpack は、一流の WordPress 開発会社である XWP と連携し、WordPress 用の高パフォーマンスのオールインワン ツールキットを作成してきました。

Jetpack は、常に最高級の WordPress 用オールインワン プラグインであり続けています。Jetpack には、25 以上のブロックと 30 以上のウィジェットが含まれており、統計、ソーシャル共有、支払いボタン、動画ホスティング、Podcast プレーヤーなど、ほとんどのウェブサイトに必要なすべての機能を 1 か所で提供します。さらに、バックアップやスパム対策、マルウェア スキャンが組み込まれているので、サイトやデータの保護という面でも安心できます。

Google や XWP を含む AMP Project の貢献者が作成した公式 AMP for WordPress プラグインは、すぐに使えるソリューションを提供します。さらに、常に高いパフォーマンスで動作するサイトを最低限のリソースで構築および保守する際に役立ちます。  

この 2 つのプラグインを使えば、美しく高速で最先端のウェブサイトを、コーディングなしで構築するために必要な機能がすべて提供されます。

スタートガイド

Jetpack のインストールと設定

1. [Plugins] > [Add New] を開きます（[サイトの URL]/wp-admin/plugins-install.php）。一覧または検索ボックスを使って Jetpack を見つけて、インストールおよび有効化します。
2. プロンプトが表示されたら、[Set Up Jetpack] をクリックします。

AMP のインストールと設定

1. 再び、[Plugins] > [Add New] を開きます（[サイトの URL]/wp-admin/plugins-install.php）。一覧または検索ボックスを使って AMP を見つけて、インストールおよび有効化します。 
2. プラグインを有効化したら、プラグインの一覧から AMP の [Settings] リンクをクリックし、[Standard Mode] で AMP プラグインを設定します。これで、サイトのすべてのページを AMP を使ってレンダリングするように WordPress を設定できます（AMP プラグインで Standard Mode を使うには、AMP 対応のテーマを利用する必要があります。AMP と Jetpack を使う際に利用できるさまざまな設定オプションについては、AMP for WordPress プラグインのサイトをご覧ください。AMP 対応のテーマを使わない場合も、これをご確認ください）。

可能性は無限大

これで完了です。準備はできました。Jetpack と AMP を使うことで、超高速で最高の SEO を実現する真に傑出したウェブサイトを構築する力が得られます。  

すばらしいウェブサイトを支えるバックボーンを設定できました。次は、Jetpack ブロックを使ってエンゲージメントの高いさまざまな種類のコンテンツを追加する方法をご確認ください。もう一度言いますが、コーディングは不要です。

タイムテーブル・アジェンダ