この記事は ソフトウェア エンジニア、David Brazdil、Nicolas Geoffray による Android Developers Blog の記事 "An Update on non-SDK restrictions in Android P" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Android で特に重視していることは、ユーザーとデベロッパーに最高のエクスペリエンスを提供することです。各 OS がリリースされるたびに、新しい機能を使用してユーザーにすばらしいエクスペリエンスを提供できるようになりますが、一部のアプリ デベロッパーが非 SDK インターフェースを使用していることを認識しています。非 SDK インターフェースを使用すると、ユーザーがクラッシュに遭遇する回数が増加し、デベロッパーは緊急リリースを配布する必要性にせまられる場合があります。私たちはこうした状況を改善したいと考えており、新しい各 OS で Android の安定性を確保するためにデベロッパーからの支援を必要としています。

3 か月前に、Android P で非 SDK インターフェースの使用を制限することを開始する計画を発表しました。私たちは、これらの制限がデベロッパーのリリース ワークフローに影響を及ぼすことを理解しており、非 SDK インターフェースの使用を検出するツールをデベロッパーに提供するとともに、新しいポリシーへの対応を計画して、フィードバックをお寄せいただくための時間を確保したいと考えています。

デベロッパー プレビューと Beta 1 では、これらの制限がアプリに及ぼす影響を視認する方法を提供しました。デベロッパー プレビューでは、制限された API の使用がログとトースト メッセージで表示されます。また、Beta 1 には、プログラムでこれらの制限を検出し、独自のロギングを行えるようにする StrictMode ポリシーを提供しました。次に例を示します。



複数の理由により、アプリで非 SDK インターフェースを使用する必要があることを理解しています。Android P でアプリが引き続き動作できるようにすることは、Google にとって重要なことです。多くのデベロッパーの皆さんから、Issue Tracker でユースケースを提示していただきました（感謝します）。お寄せいただいたほとんどのリクエストに応えて、Android P 向けの特定の非 SDK インターフェースをグレーリストに追加し、その制限を解除しています。また、私たちのチームは、多数のアプリに対して静的な解析を実行し、社内および外部のベータ版テスターからの数千個におよぶ自動レポートを処理しています。この解析を通じて、アプリが依存しているその他の非 SDK インターフェースを特定し、グレーリストに追加しています。グレーリストに含まれているすべてのインターフェースについて、今後のリリースに向けて代替となるパブリック SDK を調査します。ただし、一部の非 SDK インターフェースの使用を見落としている可能性があるため、ターゲット SDK が Android Oreo 以前のアプリでは、大部分の非 SDK インターフェースを利用できるようにしています。

まとめると、Android P で実行されるアプリには、非 SDK インターフェースの使用制限が適用されます。Android P をターゲットにしている場合、引き続き利用できる非 SDK インターフェースがグレーリストに表示されますが、その他のすべての非 SDK インターフェースにアクセスすることはできなくなります。Android Oreo 以前をターゲットにしている場合、ほとんどの制限は適用されませんが、グレーリストに含まれていない非 SDK インターフェースにアクセスすると、logcat に警告が表示されます（ユーザーには警告が表示されないことに注意してください）。

新しい Beta 2 リリースを試して、StrictMode を使用して非 SDK インターフェースの使用を検出してみてください。Beta 2 の機能は、非 SDK インターフェースの使用を制限するために最終リリースに実装される機能とほぼ同じです。また、新しいよくある質問をご覧ください。機能に関するあらゆる質問への回答が用意されていれば幸いですが、回答がない場合は、お知らせください。


Reviewed by Yuichi Araki - Developer Relations Team

この記事は Chromium Blog の記事 "Chrome 68 Beta: add to home screen, payment handler, page lifecycle" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

 特に記載のない限り、下記の変更は Android、Chrome OS、Linux、macOS、Windows 向けの最新の Chrome Beta チャンネル リリースに適用されます。Chrome 68 の完全な機能リストについては、ChromeStatus.com を参照してください。2018 年 6 月 7 日の時点で Chrome 68 はベータ版です。

プログレッシブ ウェブアプリ向けの新しい「ホーム画面に追加」動作

これまで、デベロッパーの皆さんから、ホーム画面への追加を促すプロンプトを表示する方法とタイミングをより細かく制御したいという要望が頻繁に寄せられてきました。Android 版 Chrome 68 以降では、プロンプトを表示するタイミングをより細かく制御できるようになります。ホーム画面に追加する際のエクスペリエンスに追加のコンテキストを提供し、クリック率を向上させることができるようになります。

ホーム画面に追加するためのダイアログ

サイトがホーム画面に追加するための条件を満たしている場合、Chrome で beforeinstallprompt イベントが発行されるようになり、ホーム画面に追加するためのバナーは自動的に表示されなくなります。その代わり、デベロッパーは、このイベントが発行されたときにイベントを保存して、ボタンやその他の UI 要素をアプリに追加し、アプリがインストール可能であることを示すことができます。デベロッパーは、ユーザーがインストール ボタンをクリックしたときに、保存した beforeinstallprompt イベントで prompt() を呼び出し、ホーム画面に追加するための新しいモーダル ダイアログを表示することができます。ユーザーの操作なしで beforeinstallprompt イベントを発行できますが、prompt() を呼び出すにはユーザーの操作が必要です。

let installPromptEvent;

window.addEventListener('beforeinstallprompt', (event) => {
  // Prevent Chrome <= 67 from automatically showing the prompt
  event.preventDefault();
  // Stash the event so it can be triggered later.
  installPromptEvent = event;
  // Update UI notify the user they can add to home screen
  document.querySelector('#install-button').disabled = false;
});

デベロッパーが時間的な余裕を持って、beforeinstallpromptevent を処理して、インストール ボタンをアプリに追加できるようにするための一時的な措置として、Chrome では、ホーム画面に追加するための条件を満たしているサイトにユーザーが最初にアクセスしたときに、ミニ情報バーが表示されます。ミニ情報バーは、一度消去されると、十分な時間（現在は 3 か月）が経過するまで再度表示されません。

ホーム画面に追加するためのミニ情報バー

詳細やコードサンプル、新しい UI 要素のスクリーンショットについては、ホーム画面に追加する動作の変更点をご覧ください。

Payment Handler API

Payment Request API の登場で、ブラウザ ネイティブの UI と、ユーザーが頻繁に利用する支払い方法や配送先住所を組み合わせて、オンラインの購入手続きをより簡単かつ迅速に済ませることが可能になりました。

リリースされたばかりの Payment Handler API は、Payment Request 上でウェブベースの支払いアプリが支払いを直接行えるようにします。

const request = new PaymentRequest([{
  // Your custom payment method identifier comes here
  supportedMethods: 'https://bobpay.xyz/pay'
}], {
  total: {
    label: 'total',
    amount: { value: '10', currency: 'USD' }
  }
});

Payment Request API を介した支払い。「Pay with BobPay」は、Payment Handler API を使ってビルドされたカスタム決済方法です。

望ましくない移動先からユーザーを保護する

このバージョンの Chrome では、いくつかのユーザー インターフェースの動作を変更して、ユーザー エクスペリエンスを向上させています。

クロスオリジンの iframe でのリダイレクトに対してユーザーの操作が必要になる

sandbox 属性で禁止されていない限り、通常、iframe に埋め込まれているコンテンツでは、トップレベルのブラウジング コンテキストから別のウェブサイトにナビゲートすることができます。この機能は、シングルサインオン プロバイダや決済サービスなど、さまざまなタイプのウェブサイトで使用されています。残念ながら、この動作は一般的な不正利用にもつながり、ユーザーが気付かないうちに、または同意なしに、望ましくない移動先にリダイレクトされる可能性があります。

Chrome 68 以降から、iframe に埋め込まれたコンテンツでは、トップレベルのブラウジング コンテキストから別のオリジンにナビゲートするには、ユーザーの操作が必要になります。ポップアップのブロックと同じように、この保護がトリガーされると、ユーザーには、リダイレクトの続行を許可するためのオプションを提供する Chrome UI が表示されます。

このリダイレクト動作をデモで示します。このリンク先のデモは、Chrome 67 以前の古い動作を示しています。Chrome 68 では、改善された動作が機能します。

タブアンダー ナビゲーションをブロックする

タブアンダーとは、ページで目的の移動先へのポップアップを開くと同時に、オープナー ページからサードパーティ コンテンツにナビゲートすることです。通常、この動作を利用して、ユーザーを目的の移動先に送り、その一方で望ましくない移動先が含まれた別のタブを作成します。ポップアップの場合と同じように、Chrome では、こうした望ましくないナビゲーションが防止され、その代わりに、ネイティブ UI がユーザーに表示されるため、ユーザーは、このリダイレクトに従って新しい移動先を開くかどうかを選択できるようになります。

Page Lifecycle API

アプリケーションのライフサイクルは、最新のオペレーティング システムがリソースを管理する重要な手段になります。Android、iOS、最近の Windows では、プラットフォームによってアプリをいつでも起動および終了できます。これにより、これらのプラットフォームでリソースを最適化して、ユーザーにとって最もメリットがある場所に再割り当てすることが可能になります。

ウェブでは、これまでこのようなライフサイクルがなく、アプリを無期限に実行したままにできました。実行されるウェブアプリ（およびタブ）の数が増加するにつれて、メモリ、CPU、電池、ネットワークなどの重要なリソースが過剰にサブスクライブされる場合があり、エンドユーザー エクスペリエンスの悪化につながっています。

Chrome 68 では、デベロッパーは、新しい freeze および resume イベントを使用して、バックグラウンド タブに対してシステムで開始される CPU 停止を監視して対応できるようになります。フリーズしたページを破棄してメモリを節約する必要がある場合、document.wasDiscarded プロパティを利用できるようになったため、ユーザーがタブに再度フォーカスして、ページが再読み込みされたときに、ビューの状態（freeze イベントに保存された）を復元できます。独自のアプリケーションでこれらのイベントをテストする必要があるデベロッパーは、chrome://discards にアクセスして、ページのフリーズ、再開、破棄をシミュレートすることができます。

Page Lifecycle API の詳細については、仕様または GitHub に記載した説明をご覧ください。

今回のリリースに追加されたその他の機能

CSS

overflow ショートハンドで 2 つの値を受け入れる

overflow ショートハンドが 2 つの値を受け入れるため、水平方向と垂直方向の overflow にそれぞれ別の値を設定できます。2 つの値を設定する場合、最初の値は overflow-x に、2 番目の値は overflow-y になります。ショートハンドの変更により、以前はステートメントが 2 つ必要でしたが、ステートメントを 1 つ指定するだけで済むようになりました。

3 つの部分で構成される CSS の位置の値

object-position および perspective-origin プロパティは、"top right 20%" といった、3 つの部分で構成される値を受け入れなくなりました。この変更は、基本的な図形やグラデーションにも適用されます。現在、有効な位置の値は、常に 1 つ、2 つ、または 4 つの部分で構成されます。3 つの部分で構成される値は、Chrome 66 以降でサポートされなくなりました。

解像度単位として「x」をサポート

CSS Values and Units Module Level 4 では、高解像度のディスプレイをサポートするために、「ピクセルあたりのドット数」という新しい解像度単位が定義されています。この変更により、既存の略語 'dppx' の同義語として 'x' が追加されました。

CSS のカーソル プロパティ用のプレフィックスなしの「grab」および「grabbing」値

CSS の値「grab」および「grabbing」は、マウス カーソルを開いた手や閉じた手の形に変えます。これらの値は、通常、何かを掴むことができる、または何を現在掴んでいることを示すために使用されます。Chrome 1 以降で、これらのプロパティのプレフィックスが付いたバージョンがサポートされてきました。この変更により、Chrome では、これらの値のプレフィックスなしの標準バージョンがサポートされるようになります。

ゲームパッド

ゲームパッドの高解像度タイムスタンプ

Gamepad.timestamp では、マイクロ秒の解像度を備えた高解像度のモノトニック時刻である DOMHighResTimeStamp が使用されるようになりました。タイムスタンプは、PerformanceTiming.navigationStart プロパティからのオフセットとして計測されます。

カスタム要素

新しい customElements.upgrade()

この関数は、コンストラクタがまだ明示的に呼び出されていないカスタム要素のカスタム要素コンストラクタを呼び出します。innerHTML setter でカスタム要素が作成され、その親ノードがドキュメントに接続されていない場合、親ノードが接続されるまで、カスタム要素コンストラクタは呼び出されません。このメソッドを使用すると、デベロッパーは、接続状態に関係なく、カスタム要素コンストラクタを呼び出すタイミングを明示的に完全に制御できるようになります。

入力

キーボードのロック

全画面表示のときにこの API を使用すると、Cmd-Tab / Alt-Tab、Esc など、通常はシステムやブラウザによって処理されるキー操作をアプリで受け取ることができます。ユーザーは、Esc キーを 2 秒間押すことにより、キーボードのロック（および全画面）を解除することができます。

PointerEvent.fromElement と PointerEvent.toElement を null にする

他のブラウザとの整合性を向上させるために、fromElement フィールドと toElement フィールドの PointerEvents で、常に null をレポートすることにより、Pointer Events Level 2 仕様に準拠しないようにしています。

MouseEvent（PointerEvent によるこれらのフィールドの継承元）では、fromElement と toElement は非標準であり、主要なブラウザの間で長年にわたって一貫性がありませんでした。また、一貫性のある標準の代替イベントである target と relatedTarget が既に存在します。

統合されたタップ調整

タップ調整により、TouchEvent および対応する PointerEvent のターゲットがタップエリア内の最適なターゲットに変更されました。TouchEvent の座標は変更されません。

長押しをユーザー操作として扱う

長押しはユーザーによるページの操作を示すため、ユーザーの操作と見なされるようになりました。これにより、ウェブアプリで長押しすると、navigator.vibrate() などの制限された API を呼び出して、ネイティブの動作に一致させることが可能になりました。

メディア

WebAudio: ユーザーによる選択が可能な AudioParam のオートメーション レートを追加

AudioParam.automationRate
属性を使用すると、ユーザーが AudioParam に「a-rate」または「k-rate」のいずれかを指定できるようになります。仕様で説明されているように、すべてではありませんが、ほとんどの AudioParam 属性では、レートを変更することができます。

たとえば、デフォルトの「a-rate」オートメーションを備えた BiquadFilterNode は、パラメータとフィルタ係数間の関係が複雑なため、計算の負荷が大きくなります。この高速のオートメーションが不要な場合（最も一般的なケース）、パラメータを「k-rate」に設定することができます。

ServiceWorker

Service Worker スクリプトのキャッシュ管理を改善する

Service Worker にアップデートをリクエストすると、HTTP キャッシュが無視されるようになります。importScripts のリクエストは、引き続き HTTP キャッシュを経由しますが、これはデフォルトの動作です。この動作を制御する新しい登録オプション ServiceWorkerRegistration.updateViaCache が利用できます。
以前は、Service Worker のアップデートを確認する HTTP リクエストは、デフォルトで HTTP キャッシュによって実行されていました。Service Worker 上に Cache-Control ヘッダーが意図せずに設定されると、Service Worker のアップデートが遅延する可能性がありました。また、サイトの他のアセットのバージョン情報が Service Worker に含まれている場合、それらのアップデートも遅延していました。

サポートの終了予定と相互運用性の改善

Chrome では、他のブラウザとの相互運用性を高めるために、機能のサポートの終了、削除、変更を行う場合があります。このバージョンの Chrome では、以下の変更が行われています。

フィルタの負の輝度値のサポート終了と削除

仕様に準拠するために、フィルタの brightness() 関数が負の値を受け取らなくなりました。

document.createTouch の削除

Chrome 48 以降では Touch() コンストラクタがサポートされているため、document.createTouch() メソッドが削除されています。

Document.selectedStylesheetSet と Document.preferredStylesheetSet の削除

Document.selectedStylesheetSet 属性と Document.preferredStylesheetSet 属性は非標準であり、Chrome と WebKit のみで実装されるため、これらの属性は削除されました。これらの属性の標準バージョンは、2016 年に仕様から削除されました。

WEBGL_compressed_texture_atc

Chrome では以前、AMD_compressed_ATC_texture フォーマットが提供されていました。ハードウェアのサポートがほぼゼロに縮小したため、WebGL Working Group は、この拡張機能を棄却しています。この拡張機能のサポートは削除されています。


Reviewed by Eiji Kitamura - Developer Relations Team

この記事は  Mertcan Mermerkaya、ソフトウェア エンジニアによる The Firebase Blog の記事 "Web Notifications API Support Now Available in FCM Send v1 API" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


Firebase Cloud Messaging を使用してクライアントに通知を送信しているウェブ デベロッパーの皆さんに、すばらしいニュースがあります。FCM v1 REST API が Web Notifications API と完全に統合されました。この統合により、サーバーからのウェブ通知にアイコン、画像、アクションを設定できるようになりました。さらに、Web Notifications API の成長と変化は続き、新たなオプションが追加されても、すぐに利用できるようになります。オプションをサポートするために FCM のアップデートを待つ必要はありません。

Push API がサポートされているブラウザでウェブ クライアントに送信できるペイロードのサンプルを次に示します。この通知は、画像の投稿をサポートしているウェブアプリに効果的で、アプリに対するユーザーのエンゲージメントを高めることができます。

{
  "message": {
    "webpush": {
      "notification": {
        "title": "Fish Photos 🐟",
        "body":
          "Thanks for signing up for Fish Photos! You now will receive fun daily photos of fish!",
        "icon": "firebase-logo.png",
        "image": "guppies.jpg",
        "data": {
          "notificationType": "fishPhoto",
          "photoId": "123456"
        },
        "click_action": "https://example.com/fish_photos",
        "actions": [
          {
            "title": "Like",
            "action": "like",
            "icon": "icons/heart.png"
          },
          {
            "title": "Unsubscribe",
            "action": "unsubscribe",
            "icon": "icons/cross.png"
          }
        ]
      }
    },
    "token": "<APP_INSTANCE_REGISTRATION_TOKEN>"
  }
}

アクションなどの新しいパラメータを設定すると、ユーザーが通知をさまざまな方法で操作できるようになることに注目してください。以下の例では、ユーザーは、写真の高評価や登録解除などのアクションを選択できます。


アプリでアクションのクリックを処理できるようにするには、デフォルトの firebase-messaging-sw.js ファイル（または、カスタム Service Worker）にイベント リスナーを追加する必要があります。アクション ボタンがクリックされると、event.action には、クリックされたアクションの識別文字列がセットされます。クライアントで「like」イベントと「unsubscribe」イベントを処理する方法を次に示します。

// Retrieve an instance of Firebase Messaging so that it can handle background messages.
const messaging = firebase.messaging();

// Add an event listener to handle notification clicks
self.addEventListener('notificationclick', function(event) {
   if (event.action === 'like') {
       // Like button was clicked

       const photoId = event.notification.data.photoId;
       like(photoId);
   }
   else if (event.action === 'unsubscribe') {
       // Unsubscribe button was clicked

       const notificationType = event.notification.data.notificationType;
       unsubscribe(notificationType);
   }

   event.notification.close();
});

SDK は引き続き通常の通知クリックを処理し、提供されている場合は click_action リンクにユーザーをリダイレクトします。クライアントでクリック アクションを処理する方法の詳細は、このガイドをご覧ください。

ブラウザによってサポートされるプラットフォームやパラメータが異なるため、ブラウザの互換性に関するドキュメントを参照して、通知が意図したとおりに機能することを確認する必要があります。Send API が実行できる処理についてさらに知りたい方は、FCM Send API のドキュメントと Web Notifications API のドキュメントをご覧ください。FCM Send API を使用して、Web Notifications API を素晴らしい方法で組み込んでいる方は、ぜひお知らせください。Twitter で @Firebase をフォローしたり、Facebook や Google+ で「Firebase」を検索してください。


Reviewed by Khanh LeViet - Developer Relations Team

この記事はプラットフォームおよびエコシステム、デベロッパー マーケティング、Patricia Correaによる Android Developers Blog の記事 "#IMakeApps - Celebrating app makers worldwide" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Android のデベロッパー エコシステムを作り上げているのは、さまざまなバックグラウンドや関心、夢を持った並外れた人々です。私たちのコミュニティを作り上げている人々を祝福するために、本日（*原文公開当時）から数か月にわたって、世界中のデベロッパー、創設者、プロダクト マネージャー、デザイナーなど、さまざまな人々と会い、抱いている情熱について語ってもらうとともに、コンピュータから離れているときの活動について伺いたいと考えています。

Polarsteps の共同創立者であり冒険家の Niek Bokkers（オランダ）、Quiltuduko をデザインしたアーティストの Faith Ringgold（米国）、Be My Eyes を開発した椅子修復家の Hans Jorgen Wiberg（デンマーク）のストーリーをご覧ください。ストーリーとアプリの詳細については、g.co/play/imakeapps でご覧いただけます。

ストーリーをお寄せください

皆さんのストーリーもお聞かせください。ソーシャル メディア チャンネルでハッシュタグ #IMakeApps を使って、開発中のアプリやゲーム、開発中に果たしている役割、そして仕事を離れているときの皆さんを最もよく表している画像を共有してください。Google のチャンネルで、定期的に人気のあるストーリーをいくつか選択して共有する予定です。

また、近日中に公開予定の #IMakeApps の映画に登場したい方は、こちらの自己推薦フォームに自己紹介とアプリやゲームの詳細を記入してください。

Twitter、YouTube、LinkedIn でフォローして、#IMakeApps のストーリーに関する最新情報をご確認ください。


Reviewed by Takuo Suzuki - Developer Relations Team

この記事は G Suite デベロッパー アドボケート、Wesley Chun（@wescpy）による Google Developers Blog の記事 "Developing bots for Hangouts Chat" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

先日、Hangouts Chat を一般公開しました。この次世代のメッセージング プラットフォームは、チーム内でコミュニケーションを取って連携する新たな場を G Suite のユーザーに提供します。また、アーカイブと検索、より緊密な G Suite の統合、個別のスレッド化されたチャットルームを作成する機能を備えています。デベロッパー向けの新しい重要な機能として、ボット フレームワークおよび API が組み込まれています。ボットの使用により、一般的なタスクの自動化、情報の照会、その他の負荷のかかる作業の実行など、私たちの仕事の方法を大きく変えることができます。

Hangouts Chat では、書式なしテキストによる応答に加えて、 カードと呼ばれる高機能なユーザー インターフェース（UI）を使ったボット応答を表示することもできます。 この応答では、ヘッダー情報、構造化データ、イメージ、リンク、ボタンなどがレンダリングされます。さらに、ユーザーはこれらのコンポーネントを操作して、表示されている情報をアップデートすることもできます。G Suite Dev Show のこの最新のエピソードをご覧いただくと、アップデート可能なインタラクティブなカードを備えたボットを作成する方法を学習できます。


この動画で説明しているように、メッセージを受け取った際のボットの最も重要な動作は、イベントタイプを判別して、適切なアクションを実行することです。たとえばボットは、一般的に専門用語で「スペース」と呼ばれるチャットルームやダイレクト メッセージ（DM）で目的の「ペーパーワーク」が追加または削除されたときに、その「ペーパーワーク」を実行します。

最もよくあるシナリオは、ユーザーが送信した通常のメッセージを受信することです。この場合、ほとんどのボットは、リクエストの処理に関して「自分の仕事」を実行します。最後のイベントタイプは、ユーザーがインタラクティブなカードをクリックすると発生します。ボットは、標準的なメッセージを受信した場合と同じように、カード自体のアップデートなど、必要なアクションを実行します。これらの 4 つのイベントタイプをまとめた次の擬似コードは、イベントタイプに応じてボットが実行する可能性が高いアクションを表しています。

function processEvent(req, rsp) {
  var event = req.body; // event type received
  var message;          // JSON response message

  if (event.type == 'REMOVED_FROM_SPACE') {
      // no response as bot removed from room
      return;

  } else if (event.type == 'ADDED_TO_SPACE') {
    // bot added to room; send welcome message
    message = {text: 'Thanks for adding me!'};

  } else if (event.type == 'MESSAGE') {
    // message received during normal operation
    message = responseForMsg(event.message.text);

  } else if (event.type == 'CARD_CLICKED') {
    // user-click on card UI
    var action = event.action;
    message = responseForClick(
        action.actionMethodName, action.parameters);
  }

  rsp.send(message);
};

このボットの疑似コードおよび動画で紹介したボットは 同期的に応答します。時間がかかる操作またはアウトオブバンド通知を発行する操作を実行するボットは、メッセージを スペース に 非同期的に 送信できます。これらの操作には、ジョブ完了通知などのメッセージ、サーバーがダウンした場合のアラート、新しいリードが CRM（顧客管理）システムに追加された際の営業チームに対する ping などが含まれます。

Hangouts Chat では、JavaScript、Python、Google Apps Script、Google App Engine など、多くの言語とプラットフォームがサポートされます。Apps Script 上で実行されている JavaScript を使用することは、組織内でボットをオンラインで実行する最も簡単で速い方法の 1 つですが、ボットを Node.js に簡単に移植して、さまざまなホスティング オプションに使用することもできます。同様に、App Engine を使用すると、拡張性が向上し、Python 以外の追加言語（Java、PHP、Go など）をサポートできます。また、ボットを Flask に移植して、その他のホスティング オプションに使用できます。1 つの重要なポイントはプラットフォームの柔軟性です。つまり、デベロッパーはあらゆる言語、スタック、クラウドを使用して、ボットの実装を作成およびホストすることができます。ボットは、Hangouts Chat サービスから HTTP POST リクエストを受け取るだけで機能します。

先月の Google I/O 2018 で、Hangouts Chat チームリーダーと私は、長時間にわたり、より高いレベルのボット フレームワークの概要について発表を行いました。フレームワークに関するこの包括的なツアーでは、サンプル ボットの多数のライブデモに加えて、さまざまな言語とプラットフォームを紹介しています。次の 40 分ほどのセッションをご覧ください。


使い始めるにあたって、ボット フレームワークの導入に関する投稿をご覧ください。こちらの投稿では、動画で紹介されている投票ボットの Python App Engine バージョンについて詳しく説明しています。Hangouts Chat 用のボットの開発に関する詳細は、コンセプト ガイドとボットを作成する「方法」をご覧ください。ご自分の組織、顧客、そして世界を対象にボットをビルドできます。デベロッパーの皆さんがビルドするすばらしいボットを見るのを楽しみしています。



Reviewed by Eiji Kitamura - Developer Relations Team

この記事は プライバシー エンジニア、Giles Hogben、ソフトウェア エンジニア、Milinda Perera による Android Developers Blog の記事 "Project Capillary: End-to-end encryption for push messaging, simplified" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Firebase Cloud Messaging（FCM）で通信すれば、それだけで HTTPS を利用できます。FCM サーバー エンドポイントと端末間のチャンネルは、TCP を介した SSL で暗号化されます。ただし、デベロッパーのサーバーとユーザーの端末間でメッセージをエンドツーエンド（E2E）で暗号化するためには、デベロッパーが特別な措置を講じる必要があります。

そのため、ユーザーの端末で生成された鍵を使用して、プッシュ メッセージをエンドツーエンドで暗号化することをおすすめしていますが、従来より、このような E2E の暗号化を実装するには、深い技術的知識と多大な労力が必要でした。そこで、デベロッパーのサーバーとユーザーの Android 端末間でプッシュ メッセージの E2E の暗号化を簡単に実装できるようにする Capillary オープンソース ライブラリを公開しました。

また、最近ロック解除された端末のみで復号化が可能になるメッセージを送信する機能を追加しました。この機能では、ファイルベースの暗号化（FBE）を使用することにより、端末でのメッセージの復号化がサポートされます。暗号化されたメッセージは端末暗号化（DE）ストレージでキャッシュされ、メッセージの復号鍵は Android Keystore に格納されるため、ユーザーの認証が必要になります。これにより、デベロッパーは機密性の高いコンテンツが含まれるメッセージを指定できるようになります。メッセージは、ユーザーが端末をロック解除して復号化を行うまで、キャッシュされた形式で暗号化されたままになります。

このライブラリは次の処理を実行します。

• KitKat（API レベル 19）以降のすべてのバージョンの Android を対象とした暗号化機能と鍵の管理。
• 鍵の生成と登録のワークフロー。
• メッセージの暗号化（サーバー上）と復号化（クライアント上）。
• メッセージの改変を防止するための整合性保護。
• 未認証コンテキストで受信され、端末のロック解除後に復号化して表示されるメッセージのキャッシュ。
• ユーザーがアプリのインストール後に端末のロックを追加またはリセットした場合やアプリのストレージをリセットした場合などのエッジケース。

このライブラリは ECDSA 認証を使った RSA 暗号化と Web Push 暗号化の両方をサポートするため、デベロッパーは、E2E で暗号化された Web Push メッセージをブラウザベースのクライアントに送信するために開発した既存のサーバー側コードを再利用することができます。

このライブラリに加えて、デモアプリ（ついに Google のプライバシー チームまでもが独自の SMS アプリを作成しました）も公開しています。このデモアプリでは、ライブラリを使用して、E2E で暗号化された FCM ペイロードを gRPC ベースのサーバー実装から送信します。

未対応の領域

• このオープンソース ライブラリとデモアプリは、ピアツーピアのメッセージングと鍵の交換をサポートするように設計されていません。これらはデベロッパー向けに設計され、E2E で暗号化されたプッシュ メッセージをサーバーから 1 つ以上の端末に送信します。デベロッパーのサーバーと配信先端末の間でメッセージを保護できますが、端末間でメッセージを直接保護することはできません。
• この暗号化はサーバー側の包括的なソリューションではありません。コア暗号化機能は提供されますが、デベロッパーは、サンプルのサーバー側コードの一部（たとえば、メッセージの構成や公開鍵のデータベース ストレージなど）をデベロッパーのアーキテクチャ固有のものに改変する必要があります。

このライブラリとデモの設計および実装方法の技術的な詳細については、こちらをご覧ください。


Reviewed by Yuichi Araki - Developer Relations Team

先日お知らせしたように、2018 年 8 月から、Google Play ストアに提出されるすべての新しいアプリとゲームは、ターゲット SDK を API レベル 26 以上（Android 8.0 Oreo）に設定することが求められます。また、2018 年 11 月からは、この要件がアプリおよびゲームのすべてのアップデートに適用されます。これによって、セキュリティとパフォーマンスが最適化された最新の API でアプリがビルドされることが保証されます。また、2019 年 8 月にGoogle Play では、ネイティブ ライブラリを含む新しいアプリとアプリのアップデートは、32 ビット版に加えて 64 ビット版を提供することが義務づけられます。

本記事では、主にゲームに対して注意すべき重要な変更を示します。

• API 23 以降では、実行時にパーミッションをリクエストして、アプリのインストール プロセスを効率化する必要があります。 
• API 24 以降では、アプリからプライベート ライブラリに動的にリンクすることができません。自作のコードでプライベート ライブラリにリンクしていなくても、アプリ内のサードパーティの静的ライブラリでリンクしている可能性があります。そのため、すべてのデベロッパーは Android 7.0 を搭載している端末でアプリがクラッシュしないことを確認する必要があります。アプリがネイティブ コードを使用している場合は、パブリック NDK API のみを使用するようにしてください。
• ゲームで Android プッシュ通知を使用している場合は、GcmNetworkManager（GCM ライブラリを介したタスクのスケジューリング用）、Google Cloud Messaging（メッセージの受信用）、または Firebase Cloud Messaging を使用する可能性が高くなります。これらのすべての場合で、ゲームの GMS Core SDK をバージョン 9.1 以降にアップデートして、ゲームの他の部分が API レベル 26 をサポートできるようにする必要があります。
• OBB - OBB のファイルにアクセスする前に、ゲームが OBB のディレクトリにアクセスできるかどうかを確認してください。一部の端末では、端末上の問題のためにアクセス権が自動的に付与されません。この場合、API を明示的に使用してアクセス権をリクエストし、アクセス権が付与されない問題を適切に処理する必要があります。また、外部ストレージにアクセスするために、次のエントリをマニフェストに追加してください。
  <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" />

このプロセスに関するフィードバックをお寄せください。

この変更を実施する理由を教えてください。
Android は新たにバージョンを重ねるごとに、Android ユーザー向けに新しい機能強化とメリットが追加されてきました。ただし、これらの一部の改善が効果を発揮するには、アプリとゲームが積極的に最新の SDK を対象とする必要があります。これらの機能強化には、プライベート データ（連絡先や位置情報）のより適切な制御、電池寿命の改善、メモリ消費の削減、より厳密なバックグラウンド実行制限などが含まれます。

API 26 を対象とするようにゲームをアップデートするタイミングを教えてください。
できる限り早めにアップデートすることをおすすめします。少なくとも、Android 8.0 Oreo SDK（API レベル 26）にアプリをインストールしてみて、ゲームに非互換性 / 問題があるかどうかを確認する必要があります。

Android 8.0 を対象とするようにアップデートするには、どれくらいの作業量が必要ですか。
いくつかの要素によって左右されます。ゲームにアップデートを定期的に追加していて、最新の Android SDK を積極的に対象としている場合、API 26 を既に対象としているか、API 25 から API 26 に移行するだけで済む可能性があります。

ただし、ゲームが古く、API 26 と互換性のないサードパーティ SDK を使用している場合、これらの外部依存関係をアップデートして、当該の変更に対応する必要があります。

互換性のない広告ネットワークまたは SDK を使用しています。何をすればよいですか。
最初に、見つけた問題点を Google にお知らせください。

次に、これらの広告ネットワークの担当者または SDK デベロッパーに連絡し、この変更についての懸念をお伝えください。Google は、すべてのユーザーの利益のために Android エコシステム全体がこの変更に対応するよう働きかけています。

マニフェスト ファイルだけが変更されるのですか。
マニフェストの変更は開始点に過ぎません。現在使用している API バージョンと API 26 間の動作変更点にアプリが対応できることを確認する必要があります。次の記事をご覧ください。

• https://developer.android.com/about/versions/oreo/android-8.0-changes.html
• https://developer.android.com/about/versions/nougat/android-7.0-changes.html
• https://developer.android.com/about/versions/marshmallow/android-6.0-changes.html
• https://developer.android.com/about/versions/android-5.0-changes.html

現在、API 17 よりも前の API を対象としています。どうなりますか。
Android P 端末でアプリ実行に警告が表示されます。アプリを API 17 にアップデートすることを優先し、P 端末でアプリ実行に警告が表示されないよう、対応をお願いします。

64 ビットのサポートを追加する意味は何ですか。
64 ビット環境でアプリを実行できるようになり互換性が向上します。また、パフォーマンスにも若干の良い影響があります。この変更は 2019 年 8 月から適用されます。

毎年、アプリで最新の API を対象とする必要がありますか。
アプリは、Android の各メジャー リリースの後、「最新 API レベルを対象とする」必要があります。つまり、Android の前回のメジャー リリースを対象とすることになり、P リリースには Oreo を、Q リリースには P を使用します。

Unity を使用してゲームをビルドしていますが、何か影響がありますか。
おそらく影響を受けます。デフォルトでは、Unity により、マシンにインストールされている最高レベルの SDK に TargetSDK が自動的に設定されます。したがって、Unity 向けの Android ビルド設定（[Build Settings] > [Android] > [Player Settings]）をチェックして、選択されている現在のターゲット API レベルを確認する必要があります。Android Studio を開き、「[Tools] > [Android] > [SDK Manager] > [Android SDK] > [SDK Platforms]」に移動すると、Android 8.0 Oreo がインストールされていることを確認して、最新の SDK をインストールできます。

私たちは、デベロッパーの皆さんと、デベロッパーの皆さんがビルドするゲームを高く評価しています。これらのポリシー変更に驚かれるかもしれませんが、これらの変更は、Android エコシステムを前進させて、その有用性を維持するために重要であると考えています。デベロッパーの皆さんからのフィードバックは大歓迎であり、このプロセスに対するサポートをいつでも提供いたします。


Posted by Hak Matsuda - Developer Relations Team

この記事は  Josh Radcliff、AdWords API チーム による Google Ads Developer Blog の記事 "Announcing v201806 of the AdWords API" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


この記事は Nadine Sundquist、AdWords API チームによる Google Ads Developer Blog の記事 "Announcing v0_1 of the Google Ads API" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


この記事は Google+、LinkedIn、Medium トレーニング デベロッパー & ワード アーティスト、Aleks Haecky による Android Developers Blog の記事 "Learn Kotlin Fast with new Kotlin Bootcamp course" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Udacity の Kotlin ブートキャンプ コースは、Kotlin プログラミング言語の基礎を自分のペースで学ぶことができる無料のオンライン コースです。Kotlin のこの入門コースは、Google のエキスパートと Udacity が共同で開発し、プログラミングについて既に知識がある方を対象にしています。


Kotlin 言語を使用すると、より短時間に、少ないコードで、エラーの少ないアプリを作成できます。

この最新のオブジェクト指向の言語は、強力な型システム、型推測、null 安全性、プロパティ、ラムダ式、拡張機能、コルーチン、高次の関数のほか、その他の多くの機能を備えています。Kotlin はとても簡潔で、1 行のコードで完全なデータ クラスを作成できます。

Kotlin は Android アプリのビルド向けに公式にサポートされています。また、Java プログラミング言語と完全に相互運用でき、IntelliJ と Android Studio に含まれています。

このコースでは、Kotlin でプログラミングするために必要な次のような技能をすべて学ぶことができます。

1. 基本: null 許容型および null 非許容型の変数、データ型、演算子、制御構造を使用して、IntelliJ REPL Kotlin インタープリターで Kotlin のステートメントと式を記述します。
2. 関数: main() 関数の作成やデフォルト引数および変数引数を持つ呼び出し関数の作成のほか、関数を引数としてフィルタに渡したり、簡単なラムダ式、関数型、コンパクトな単一式関数をプログラミングします。
3. クラス: メソッドとプロパティを使用してクラスを作成します。コンストラクタと init() を実装します。継承、インターフェース、抽象クラスについて学習します。特定用途のクラスのデータ、オブジェクト、列挙型、sealed を使用します。
4. 応用: ペア、コレクション、定数の詳細を学びます。拡張機能の記述、ジェネリックの実装、アノテーションの適用、ラベル付きの break の使用方法について学習します。
5. 関数の操作: ラムダ式、高次の関数、インラインの詳細を学習します。

拡張関数を使用して便利な機能を既存のクラスに追加する方法を学習します。

fun Int.print() = println(this)
5.print() // prints 5

fun Context.toast(text: CharSequence, duration: Int = Toast.LENGTH_SHORT): Toast {
   return Toast.makeText(this, text, duration).apply { show() }
}
toast("Hello Toast")

class AquariumPlant(
       val color: String)

fun AquariumPlant.print() =
       println("Pretty Aquarium Plant")

val plant = AquariumPlant("green")
plant.print()
// prints -> Pretty Aquarium Plant

コースを完了すると、Kotlin でプログラムを作成して、Kotlin 独自の機能を活用できるようになります。

このコースは Udacity でオンライン講座として無料で公開されているため、自分のペースでいつでも受講できます。

https://www.udacity.com/course/ud9011 にアクセスして、より少ないコードでアプリをビルドする方法を学んでください。


Reviewed by Yuichi Araki - Developer Relations Team

この記事は AdWords API チーム代表、Adam Ohren による の記事 "Learn with us: Google Ads API webinars" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


この記事は Chrome セキュリティ プロダクト マネージャー、Emily Schechter による Chromium Blog の記事 "Evolving Chrome's security indicators" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

以前、すべての HTTP ページを断定的に「保護されていません」とマークし、HTTPS ページのセキュア インジケーターを削除するという提案を投稿しました。ウェブでは HTTPS の使用が開始されており、Google は Chrome のセキュリティ インジケーターを進化させています。この方針に沿って、年内にいくつかの追加措置を講じます。

ユーザーはウェブが安全であることが当たり前であり、問題がある場合は警告が出されると想定しています。Google は間もなく、すべての HTTP ページを「保護されていません」とマークし、Chrome のポジティブなセキュリティ インジケーターを削除することで、安全であることをデフォルトとして扱います。Chrome では、こうした措置を徐々に講じる予定で、2018 年 9 月（Chrome 69）から「保護された通信」というマークと HTTPS スキームの削除を開始します。



以前は、HTTP を使用するページが多すぎたため、すべての HTTP ページを赤色の強い警告でマークできませんでしたが、2018 年 10 月（Chrome 70）から、ユーザーが HTTP ページにデータを入力すると、赤色の「保護されていません」警告を表示する予定です。



これらの一連の変更により、デフォルトで安全な使いやすいウェブへの道が開かれることを期待しています。HTTPS は従来よりも低コストかつ簡単になりました。HTTPS を通じて強力な機能を引き出せるので、すぐに HTTPS に移行してください。導入にあたっては、Google のセットアップ ガイドをご確認ください。


Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Malte Ubl、Ben Galbraith による Chromium Blog の記事 "The State of the Web at Google I/O 2018" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

ウェブは世界にとって貴重な存在で、多くのメリットを備えています。ウェブは比類のない配信プラットフォームで、世界中の人々がさまざまなコンテンツにアクセスでき、企業はあらゆる場所の顧客にアプローチできます。ウェブの成功を支えているのはそのコミュニティとオープンな一連の規格です。こうしたコミュニティと規格のおかげで、ウェブのダイナミックな性質が維持され、すべての人々がウェブを利用できます。

Google は、PageRank から Chromium に至るまで、ウェブの継続的な成功に深く関与してきました。先月、毎年開催されるデベロッパー カンファレンスである Google I/O で、ウェブの現状について発表し、ウェブの継続的な発展を推進して、すべての人々に対して適切に機能させようとする Google の最近の取り組みの一部を紹介しました。主要なテーマを次にまとめていますが、YouTube ですべての発表を視聴することをおすすめします。


Service Worker
Service Worker API の導入は、ウェブに最近加えられた最も重要な改善の 1 つです。Service Worker はバックグラウンドで動作して、ネットワーク リクエストを横取りし、リクエストを処理して、ウェブアプリがオフラインで動作できるようにします。そのため、デベロッパーはページの限られたライフサイクルから解放されます。Service Worker を使用すると、サイトでプッシュ通知を受け取ったり、バックグラウンドでデータを同期したりできます。Apple は今年の 3 月、iOS および MacOS に搭載された Safari 11.1 に Service Worker のサポートを追加し、Microsoft Edge には先週から Service Worker が付属するようになりました。つまり、現在、すべての最新ブラウザでこの規格がサポートされています。Service Worker の使用はアーキテクチャに対する大きな変更になる可能性があるため、手軽に使用できるように、Google は Workbox を作成し、汎用的かつ強力な多くの Service Worker パターンを使いやすい API にまとめています。このライブラリのバージョン 3 がリリースされているので、モジュールにビルドして、必要な機能のみを使用することができます。

プログレッシブ ウェブアプリ（PWA）
Service Worker は PWA の多くの機能を根底から支えています。世界中のさまざまな業種の企業が、PWA をビルドして大きな成功を収めています。PWA サイトを昨年から公開している Starbucks では、毎日のアクティブ ユーザーの数が 2 倍に増えました。実際、Google が計測したアドバタイジング サイトでは、サイトが PWA に移行した後、モバイル コンバージョン率が平均して 20% 増加しました。

多くの初期 PWA はモバイルに重点を置いていましたが、そのメリットは PC にも広がっています。Chrome では、PC に PWA を「インストール」する機能が間もなく提供されます。サイトには独自のアイコンが付与され、スタンドアロンのウィンドウで表示されます。また、ページ内検索、共有可能な URL、Google Cast のサポートなど、ユーザーがブラウザに期待する強力な機能が維持されます。I/O では、Spotify がデスクトップ PWA としてリッチメディア エクスペリエンスをどのようにデプロイしているかを紹介しました。デスクトップ PWA の「インストール」サポートは、6 月上旬に ChromeOS の Chrome 67 に追加され、今年中に Windows および macOS にも導入される予定です。



WebAssembly
WebAssembly を使用すると、C や C++ などの言語で記述された、高パフォーマンスの低レベルコードをウェブサイトで実行し、ウェブ プラットフォーム上にまったく新しいクラスのコンテンツを展開することができます。3 月に、Autodesk の AutoCAD チームはウェブ自体よりも古い 35 年の歴史を持つコードベースをコンパイルし、WebAssembly を使ってブラウザ内で直接実行できるようにしました。AutoCAD の機能がリンクされるため、使用している端末やオペレーティング システムに関係なく、ブラウザ内で CAD 図面を直接編集できるようになりました。AutoCAD のエンジニアリング チームは、単一の C++ コードベースを使用して、デスクトップ チームが変更を加えたときに、ウェブアプリにも簡単に変更を組み込めるようにしました。

コードを移植したり、独自のコードを記述したりする方法については、C ライブラリと DOM の連携を解説している WebAssembly コードラボをご覧ください。C で記述された複雑なライブラリを使用しているか、新しいコーデックをウェブ プラットフォームに組み込む必要があるか、または Unity や Unreal Engine などのエンジンを使用しているかどうかに関係なく、どの場合でも WebAssembly は有用です。

Lighthouse
Lighthouse はウェブサイトの品質を分析するためのツールで、サイトのパフォーマンスを測定し、ユーザー エクスペリエンスを改善するためのガイダンスを提供します。Lighthouse は、Chrome の DevTools 内から直接アクセスできるほか、コマンドラインから実行したり、他の開発ツールと統合したりできます。2018 年だけで、50 万人のデベロッパーがサイトに対して Lighthouse を定期的に実行しています。Google はウェブの変化が速いことを認識しています。Lighthouse を使用すると、パフォーマンスに関する最新のベスト プラクティスを常に把握できます。I/O で発表された Lighthouse 3.0 はすでに一般公開されました。

Lighthouse により、制御された環境でサイトの読み込みパフォーマンスが明確に把握できるようになります。ただし、現実世界の実際のユーザーに対するサイトのパフォーマンスを知る必要がある場合は、Chrome ユーザー エクスペリエンス レポートをご覧ください。このレポートでは、最もアクセスが多い 400 万のウェブサイトについてオリジンレベルのパフォーマンス指標が提供されます。これらのツールやその他のツールでサイトのパフォーマンスを包括的に確認する方法の詳細については、スピードツールのインフォグラフィックをご覧ください。

AMP
AMP は、さまざまな優れたユーザー エクスペリエンスを備えた信頼性の高い高速のウェブサイトをビルドするための Web Component ライブラリおよびエコシステムです。現在、4600 万個のドメインに 60 億以上の AMP ページがあり、Google 検索からのページ読み込み時間の中央値は 1 秒未満です。企業は AMP を活用して成功を収めています。たとえば、世界規模のオンライン小売りマーケットプレイスである AliExpress は、AMP を活用したプログレッシブ ウェブアプリとして新しいモバイルサイトを最近公開しました。この新しいサイトでは、非検索トラフィックのコンバージョン率が 31% も増加しました。

モバイルでコンテンツを消費する方法は変化し続けており、全画面で短いストーリーを配信する方式の人気がますます高まっています。AMP プロジェクトでは、サイトオーナーのニーズを満たすため、モバイルファーストのストーリー配信用にビルドされた豊富なウェブ コンポーネントである AMP ストーリーの開発を最近発表しました。このフォーマットの開発は継続中であり、デベロッパーの皆さんには、独自のストーリーをビルドしてみることをおすすめします。AMP チームは、デベロッパーの皆さんからのフィードバックをお待ちしています。



Web Packaging
Web Packaging は一連の新しいテクノロジーであり、Google では、ウェブ コンテンツがウェブに配布されて、ユーザーに共有される方法が Web Packaging によって再定義されるだろうと考えています。Web Packaging を使用すると、サイトオーナーは、HTTPS の整合性保証を維持しながら、他のパーティから配布されるコンテンツをバンドルすることができます。Web Packaging によって可能になる新しいユースケースを探っているときに、AMP には興味深い使用方法があることに気づきました。AMP チームおよびウェブ コミュニティとの連携を通じて、AMP ドキュメントが AMP キャッシュから提供された際にサイトオーナーの元の URL を保持できるソリューションを設計することができました。

私たちの取り組みを示すものとして、AMP プロジェクトの協力企業である Food Network と Pinterest は、以下のような Web Packaging のデモを作成しています。さらに詳しく知りたい方のために、AMP チームは、Web Packaging がユーザーとサイトオーナーにどのようなメリットをもたらすかについて、こちらの記事で詳しく説明しています。AMP アプリケーションに加えて、Web Packaging テクノロジーが可能にする未来に期待するとともに、デベロッパーからの支援を通じて構想を洗練させていくことを楽しみにしています。


Polymer
Polymer とは、再利用可能なカスタム Web Component を作成して、他のデベロッパーと共有したり、そのコンポーネントを組み合わせて高性能なメンテナンス性の高いアプリをビルドしたりできるようにする JavaScript ライブラリです。I/O では、このライブラリのバージョン 3.0 を発表しました。これにより、Polymer エコシステムが大幅にアップグレードされています。パッケージ管理システムとして NPM を、そして構成単位として ES6 モジュールを使用するためのサポートが全面的に提供されるため、Polymer ベースの Web Component を他のお気に入りのウェブ開発ツールやフレームワークと簡単に併用できるようになりました。

また、Web Component の新しい基本クラスである LitElement が導入されました。このクラスでは、Lit-HTML の表現力と Web Component が組み合わされ、最新の表現力の高いテンプレート構文を使用して軽量のリアクティブ コンポーネントを作成することがより簡単になっています。

Web Component 駆動型の PWA をビルドするための包括的な開始点となる PWA Starter Kit もリリースしました。これらの PWA は、高速で信頼性と応答性が高く、テーマ設定が可能であり、Lighthouse PWA およびパフォーマンス基準において最高点を獲得しています。

Angular
今年の I/O で、Angular チームはコミュニティの成長に関する概要を発表し、コア フレームワーク、CLI、およびバージョン 6 の Angular マテリアル ライブラリに追加されたすばらしい新機能をいくつか紹介しました。Angular は何百万人ものデベロッパーによって使用されており、大きな推進力を得て、すばらしいエコシステムが構築されています。「ng update」や「ng add」など、バージョン 6 でリリースされた新しいコマンドを使用すると、アプリケーションを最新の状態に維持できるほか、Angular チームによって引き続き安定性と革新のバランスが保たれるため、デベロッパーは開発を加速させることができます。

また、Angular チーム は、Project Ivy で Angular に加えられるいくつかの改善点を少しだけ紹介しました。これらの改善により、Angular では既存のアプリケーションと連携しながら、デバッグが簡単になり、コンパイルおよび実行がさらに高速化されます。チームは、小さな Hello World アプリケーションの形式でこれらの改善のユーティリティを紹介し、使用されない Angular 機能がアプリケーションの JavaScript バンドルから自動的に削除されることを示しました。

Google および Chrome のミッションは、コミュニティと協力して、統合された高速かつ信頼性の高い魅力的なエクスペリエンスを構築することです。オープン ウェブ プラットフォームになった新しい強力な機能と、ユーザー向けに高品質のサイトをすばやく作成できるようにする包括的な一連のツールに大きな期待を寄せています。ウェブの最新の進化に関する情報を確認するには、デベロッパー ポータルにアクセスするか、Google Developers YouTube チャンネルで今年の I/O の動画をご覧ください。今年の後半に開催される Chrome Dev Summit でデベロッパーの皆さんとお会いするのを楽しみにしています。



Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Wear OS by Google リード デベロッパー アドボケート、Hoi Lam による Android Developers Blog の記事 "Wear OS by Google: AoG support and new enhanced battery saver mode" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。



Google I/O で、Wear OS by Google Developer Preview 2 を発表しました。このアップデートでは、Actions on Google（AoG）のサポートと、新しいバッテリー セーバー モードなどの電池に関する機能強化が追加されました。

このデベロッパー プレビューには、アップデートされた Android Emulator イメージと、Huawei Watch 2 Bluetooth や Huawei Watch 2 Classic Bluetooth 用のダウンロード可能なシステム イメージが含まれています。このプレビュー リリースは、デベロッパーのみを対象としています。日常的な使用やユーザーの使用を想定したものではありません。そのため、このプレビュー リリースは手動でのダウンロードと書き込みによってのみ入手できます。リリースノートで既知の問題を確認してから、端末でダウンロードと書き込みを行ってください。

Actions on Google のサポート

Wear OS 上の Google アシスタントを改良したため、視覚的なカード、追加のサジェスチョン表示、テキスト読み上げなどの機能がサポートされるようになりました。デベロッパー向けに、Wear OS に Actions on Google のサポートを追加したので、Wear OS で既存のアクションがそのまま動作します。Actions on Google のベスト プラクティスに従うと、短くて簡潔な会話や視覚および音声フィードバックの導入など、最適な結果が得られます。この機能は Android P に依存していないため、すべての Wear 2.0 ユーザーに公開されます。

強化されたバッテリー セーバー モード

この Android P Developer Preview には、強化されたバッテリー セーバー モードが導入されます。時計がこのモードになると、時計には電源効率のよいウォッチフェイスが表示され、無線通信、タッチ スクリーン、傾けて復帰する機能などの一連のサービスがオフになります。ユーザーは、サイドボタンを押して時刻を表示できます。長押しすると完全に動作するモードに戻り、NFC を介した支払いやメッセージへの応答などのタスクを実行できます。デベロッパーは、強化されたバッテリー セーバー モードでは、アプリ、ウォッチフェイス、およびウォッチフェイスの追加機能のデータ プロバイダを利用できないと考える必要があります。

省電力機能のアップデート

前回のデベロッパー プレビューでは、省電力機能に関して多くのフィードバックをお寄せいただきました。そのため、次の 2 つの機能をアップデートしました。

• BT に接続されていない場合に Wi-Fi をオフにする機能の廃止: 前のデベロッパー プレビューでは、電力消費を抑えるため、Bluetooth に接続されていないときに Wi-Fi に接続しませんでした。ユーザーおよびデベロッパーからのフィードバックを注意深く検討した結果、この変更を取りやめることにしました。
• 制限されたバックグラウンド アクティビティとフォアグラウンド サービス: 健康およびフィットネス用アプリの多くのデベロッパーから、一日を通してユーザーの動きやその他の Vitals をアプリのバックグラウンドでモニタリングする必要があるという意見が寄せられました。バックグラウンド サービスでアラームやジョブを設定できない場合、アプリでバックグラウンド モニタリングを実行できないという指摘をいただきました。こうした種類の例外的なユースケースの場合、アプリでフォアグラウンド サービスを使用して、アラームやジョブを固定することをおすすめしています。その他のユースケースの場合、デベロッパーは、時計を充電しているときのフォアグラウンド サービスに加えて、ジョブおよびアラームの制限に注意する必要があります。この機能については、引き続き細かく調整していますので、デベロッパーの皆さんから寄せられるフィードバックやユースケースが適切な調整に役立ちます。

ブリッジ通知用のスマート リプライ

ユーザーのスマートフォンからのブリッジ通知用のスマート リプライが、以前から有効になっています。最新のデベロッパー プレビューでは、中国のユーザー向けに簡体字の中国語のサポートが導入されています。この機能は TensorFlow Lite を使った端末上モデルを活用しており、このモデルはメモリの少ない省電力端末用に最適化されています。

この機能を使用するには、リプライ アクションの setAllowGeneratedReplies を true に設定する必要があります。サンプル コード スニペットを次に示します。重要な部分が太字でハイライト表示されています。

NotificationCompat.Action action =
    new NotificationCompat.Action.Builder(R.drawable.ic_reply_white_24dp,
        replyLabel, replyPendingIntent)
        .addRemoteInput(remoteInput)
        .setAllowGeneratedReplies(true) // <--- true to enable smart replies
        // Wear OS requires a hint to display the reply action inline.
        .extend(new NotificationCompat.Action.WearableExtender()
            .setHintDisplayActionInline(true))
        .build();

また、メッセージング アプリの場合は、MessagingStyle 通知を使用することをおすすめします。推奨する理由は、この通知を使用すると、より構造化されたデータセットがアルゴリズムに提供されるからです。

フィードバックをお待ちしています

このプレビューにいくつかのアップデートが追加された後、最終的な製品版がリリースされる予定です。見つけたバグは、Wear OS by Google の Issue Tracker からお送りください。早く送っていただければ、それだけ最終リリースにバグの修正が含まれる可能性が高くなります。


Reviewed by Yoshifumi Yamaguchi - Developer Relations Team

この記事は Android Developers Blog の記事 "Android Studio 3.2 Canary" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


先月の Google I/O 2018 では、Android Studio 3.2 の最新プレビューを発表しました。このプレビューには、Android P Developer Preview、新しい Android App Bundle、Android Jetpack をサポートするすばらしい機能セットが含まれています。すぐに Canary リリース チャンネルから Android Studio 3.2 をダウンロードして、今年の最も機能が豊富なリリースの 1 つをお試しください。

Android Jetpack は、優れた Android アプリを迅速かつ簡単にビルドできるようにする、一連のライブラリ、デベロッパー ツール、およびアーキテクチャ ガイダンスです。Android Jetpack では、一般的なインフラストラクチャ コードが提供されるため、アプリを差別化することに集中できます。Android Studio 3.2 には、Navigation API を使用する視覚的な Navigation Editor、Android Slices API のテンプレート、Jetpack の新しい Android サポート ライブラリ（AndroidX）に移行するためのリファクタリング ツールなど、Jetpack をサポートするさまざまなツールが含まれています。

Android Studio 3.2 の Canary 14 リリースは、APK フォーマットを進化させた新しい Android アプリモデルである Android App Bundle もサポートします。Android Studio 3.2 を使用すると、コードを変更することなく、新しい Android App Bundle を作成して Google Play での公開に備えることができます。

Android Studio の今回のリリースは、超高速の Android Emulator スナップショット、Layout Editor のサンプルデータ、アプリが電池に及ぼす影響を測定する新しい Energy Profiler など、20 の主要な機能を備えています。これらの機能を試してみたい方は、すぐに Android Studio 3.2 のプレビューをダウンロードしてください。

これらの機能のデモ操作と開発中のその他の機能の概要については、Google I/O 2018 セッションの 1 つである Android 開発ツールの新機能をご覧ください。



主なデベロッパー フローごとに分類された、Android Studio 3.2 のすべての新機能のリストを次に示します。

開発

• Navigation Editor - Android Studio 3.2 には、アプリの画面間のナビゲーション構造を設計するための新しい方法が Jetpack の一部として組み込まれています。Navigation Editor は、Jetpack の新しい Navigation コンポーネントを使用して、サポートされる XML リソースを作成できるようにする視覚的なエディタです。

• AndroidX のリファクタリング サポート - Jetpack のコンポーネントの 1 つによって、Android Support Library が見直され、新しい Android 拡張機能ライブラリ（AndroidX）名前空間にリファクタリングされます。この移行を支援するため、Android Studio 3.2 では、AndroidX の初期プレビューの一部として新しいリファクタリング操作を利用できます。この機能を使用するには、[Refactor] → [Refactor to AndroidX] を選択します。AndroidX 名前空間に移行していない Maven 依存関係がある場合、リファクタリング プロセスに対する追加の拡張機能として、Android Studio のビルドシステムにより、それらのプロジェクト依存関係も自動的に変換されます。gradle.properties ファイルで android.enableJetifier = true フラグを切り替えて、この変換プロセスを手動で制御することができます。リファクタリング操作では一般的なプロジェクト設定がサポートされますが、リファクタリングを行う前に、プロジェクトのバックアップを保存することをおすすめします。詳細はこちらをご覧ください。

• サンプルデータ - 多くの Android レイアウトには、アプリ開発の設計段階でレイアウトの外観や操作性を視覚化することが難しい場合があるランタイム データが含まれています。Layout Editor のサンプルデータは、プレースホルダ データを使ったアプリの設計に役立ちます。RecyclerView や ImageView、TextView で、Layout Editor のポップアップ ウィンドウから組み込みのサンプルデータを追加して、これらのビューを設定することができます。この機能を試すには、新しいレイアウトに RecyclerView を追加してから、デザイン時属性の新しいツールアイコンをクリックし、サンプルデータ テンプレートのカルーセルから項目を選択します。

• マテリアル デザインのアップデート - マテリアル デザインは、デザイン システムとしてだけでなく、Android への実装に関しても進化し続けています。Android Studio 3.2 では、Android デザイン サポート ライブラリから新しい MaterialComponents アプリテーマおよびライブラリへの移行を開始するときに、BottomAppBar などの新しくアップデートされたウィジェット、ボタン、カード、テキスト フィールド、新しいフォント スタイルなどへのアクセスが提供されます。詳細はこちらをご覧ください。

• Slices のサポート - Slices は、アプリ コンテンツの一部を Android オペレーティング システムの他のユーザー インターフェース サーフェスに埋め込む新しい方法です。Slices は Android 4.4 KitKat（API 19）と後方互換性があり、Google 検索の候補としてアプリ コンテンツを表示できるようにします。Android Studio 3.2 は、新しい Slice Provider API でアプリを拡張するときに役立つ組み込みのテンプレートに加えて、ベスト プラクティスに従って Slices を作成できるようにする新しい lint チェックを備えています。Slices の作成を開始するには、プロジェクト フォルダを右クリックし、[New] → [Other] → [Slice Provider] を選択します。Slices の動作をテストする方法については、スタートガイドをご覧ください。

• CMakeList の編集サポート - Android Studio は、アプリの C/C++ コード向けの CMake ビルド スクリプトをサポートします。Android Studio 3.2 のこのリリースでは、一般的な CMakeList コマンドでコード補完と構文ハイライトが機能するようになりました。

• 新機能を通知するアシスタント パネル - Android Studio 3.2 には、アップデート後に自動的に開いて、IDE に加えられた最新の変更を通知する新しいアシスタント パネルが用意されています。[Help] → [What's New in Android Studio] を選択して、パネルを開くこともできます。

• IntelliJ プラットフォーム アップデート - Android Studio 3.2 には、データフロー分析、Git へのコミットの部分的なサポート、多数の新しいコード分析機能強化など、数多くの新機能を備えた IntelliJ 2018.1 プラットフォーム リリースが含まれています。詳細はこちらをご覧ください。

ビルド

• Android App Bundle - Android App Bundle は、より小さな APK をユーザーに配信できるように設計された新しいアプリ公開フォーマットです。Google Play は、Android App Bundle を受け入れ、特定の端末に必要な APK のみを配信する新しいダイナミック配信プラットフォームを備えています。Android Studio 3.2 を使用すると、Android  App Bundle を作成およびテストすることができます。最新の Android Gradle プラグイン（com.android.tools.build:gradle:3.2.0-alpha14）を実行していれば、アプリのコードに変更を加えることなく、言語、画面密度、ABI に基づいて、コードを App Bundle として再ビルドして、より小さな APK のメリットを享受できます。App Bundle の作成を開始するには、[Build] → [Build Bundle / APK]、または [Build] → [Generate Signed Bundle / APK] を選択します。詳細はこちらをご覧ください。

• D8 desugar - 新しい Java 言語機能には新しいバイトコードと言語 API が必要な場合がありますが、古い Android 端末では、これらの機能がサポートされていないことがあります。desugar を利用して、ビルドプロセスで新しいバイトコードと言語 API を古いバイトコードと言語 API に置き換えると、これらの機能を古い端末で使用できます。desugar は、Android Studio 3.0 で別個のツールとして最初に導入されましたが、Android Studio 3.1 では、desugar ステップが試験運用版機能として D8 ツールに組み込まれたため、全体的なビルド時間を短縮できるようになりました。現在、Android Studio 3.2 では、D8 desugar はデフォルトで有効になります。古い端末を対象にしている場合に、最新のほとんどの言語機能変更点を活用できるようになりました。

• R8 オプティマイザ - Android Studio ではこれまで、アプリのビルドプロセスで ProGuard を使用して、Java 言語バイトコードを最適化および圧縮してきました。Android Studio 3.2 以降では、ProGuard の代替として、R8 の使用に移行し始めています。R8 を試すには、android.enableR8=true を gradle.properties ファイルに追加します。R8 はまだ試験運用版ですので、現時点では、R8 を使用してアプリを公開することはおすすめしません。詳細はこちらをご覧ください。

テスト

• Emulator スナップショット - Android Emulator のクイックブートを介して、エミュレータを 6 秒未満で起動できるようにしています。Android Studio 3.2 では、この機能が拡張されたため、エミュレータのあらゆる状態でスナップショットを作成して、スナップショットを 2 秒未満で起動できるようになりました。アプリをテストおよび開発するときに、指定する必要のあるプリセット、アプリ、データ、設定で Android Virtual Device (AVD) スナップショットを事前設定して、同じスナップショットに繰り返し戻ることができます。スナップショットは 2 秒未満で読み込まれ、Android Emulator の [Extended Controls] パネル、コマンドライン（./adb emu avd snapshot load snap_2018-04-29_00-01-12）、または Android Studio 内から特定のスナップショットを起動することができます。

• Android Emulator での画面録画 - 通常、アプリ画面の画面録画の作成については、Android 4.4 KitKat（API 19）以降のみでオーディオなしで機能し、Android Emulator のサポートは限定的です。最新の Android Emulator（v27.3 以降）では、すべての API レベルでオーディオ付きの画面録画を作成できます。また、組み込みの変換を介して GIF または WebM に出力することができます。Android Emulator の [Extended Controls] パネル、コマンドライン（./adb emu screenrecord start --time-limit 10 /sample_video.webm）、および Android Studio から新しい画面録画機能をトリガーすることができます。

• Android Emulator の仮想シーンカメラ - 仮想環境内の拡張現実（AR）エクスペリエンスで繰り返し使用できる新しい仮想シーンカメラを活用すると、ARCore でアプリを開発およびテストすることがさらに簡単になります。AR アプリ用の ARCore API と連動するようにエミュレータを調整して、仮想シーンのビットマップ画像を挿入することができます。標準の HAL3 互換カメラとして仮想シーンカメラを使用することもできます。使用を開始するには、Android Emulator 内で組み込みの Android カメラアプリを開きます。デフォルトでは、新しい仮想シーンカメラは、Android Studio 3.2 で作成される新しい Android Virtual Device のリアカメラになります。詳細はこちらをご覧ください。

• ADB Connection Assistant - Android Studio 3.2 は、ADB を介した Android 端末接続のトラブルシューティングを支援する新しいアシスタントを備えています。ADB Connection Assistant では、Android 端末を開発マシンに接続する際のトラブルシューティングの一般的な手順が提示されます。[Run] ダイアログ ボックスから、または [Tools] → [Connection Assistant] を選択して、このアシスタントを起動できます。

最適化

• Energy Profiler - スマートフォンの多くのユーザーにとって、電池寿命は主要な懸念事項であり、認識している以上にアプリが電池寿命に影響を及ぼしている場合あります。パフォーマンス プロファイラ スイートの新しい Energy Profiler を使用すると、Android 端末上のアプリが電力に及ぼす影響を把握することができます。また、システム コンポーネントの推定電力使用量を可視化できるほか、電池を浪費している可能性があるバックグラウンド イベントを調査することができます。Energy Profiler を使用する場合は、Android 8.0 Oreo（API 26）以降を実行している Android 端末またはエミュレータに接続している必要があります。詳細はこちらをご覧ください。

• System Trace - CPU Profiler の新しい System Trace 機能を使用すると、アプリがシステム リソースをどのように使用しているかを詳細に調べることができます。スレッドの状態の正確なタイミングと継続時間を調べたり、すべてのコアにわたって CPU ボトルネックが発生している箇所を可視化したり、カスタム トレース イベントを追加して分析したりできます。System Trace を使用するには、アプリのプロファイリングを開始し、CPU Profiler をクリックしてから、System Trace の記録構成を選択します。詳細はこちらをご覧ください。

• Profiler セッション - Android Studio を開いているときに、Profiler のデータが「セッション」として自動的に保存されるため、後でセッションを再度開いて調査できます。また、後で他のツールを使って分析または調査できるように、CPU 記録とヒープダンプをインポートおよびエクスポートする機能を追加しました。

• 自動 CPU 記録 - Debug API を使用して、CPU アクティビティを自動的に記録できます。アプリを端末にデプロイした後、アプリで startMethodTracing(String tracePath) が呼び出されると、Profiler によって CPU アクティビティが自動的に記録され、アプリで stopMethodTracing() が呼び出されると、CPU アクティビティの記録が停止します。同様に、実行の構成でこのオプションを有効にして、アプリの起動時に CPU アクティビティの記録を自動的に開始することもできます。

• JNI リファレンス トラッキング - Android アプリで C/C++ コードを使用している方のために、Android Studio 3.2 では、Memory Profiler で JNI コードのメモリ割り当てを調べることができるようになりました。Android 8.0 Oreo（API 26）以降を実行している端末にアプリをデプロイしている場合は、JNI リファレンスから割り当てコールスタックを詳しく調べることができます。この機能を使用するには、Memory Profiler セッションを開始し、[Live Allocation] プルダウン メニューから [JNI Heap] を選択します。

最新の Canary 版 Android Studio 3.2 に含まれる主な新機能をまとめます。

開発 Navigation Editor AndroidX リファクタリング サンプルデータ マテリアル デザインのアップデート Android Slices CMakeList 編集 新機能を通知するアシスタント パネル 新しい lint チェック IntelliJ プラットフォーム アップデート ビルド Android App Bundle D8 desugar R8 オプティマイザ	テスト Android Emulator スナップショット Android Emulator での画面録画 Android Emulator の仮想シーンカメラ ADB Connection Assistant 最適化 Energy Profiler System Trace Profiler セッション 自動 CPU 記録 JNI リファレンス トラッキング

詳細は、プレビュー リリースノートをご覧ください。

スタートガイド

ダウンロード

最新バージョンの Android Studio 3.2 は、Canary チャンネル ダウンロード ページからダウンロードしてください。Android Studio の以前の Canary リリースを使用している場合は、Android Studio Canary 14 以降にアップデートする必要があります。Android Studio の安定バージョンを保持する必要がある場合、Android Studio の安定リリース バージョンと Canary リリース バージョンを同時に実行することができます。詳細はこちらをご覧ください。

上記の Android Emulator 機能を使用するには、Android Studio SDK Manager を介してダウンロードした Android Emulator v27.3 以降を実行している必要があります。

気に入った機能や問題点、新機能の提案などの初期フィードバックは大歓迎です。プロダクトの品質を維持するため、Canary チャンネルにある機能は、安定版として使用できる用意ができるまで、次の安定版リリース チャンネルで利用できない場合があることに注意してください。バグや問題を見つけた方は、ご遠慮なく問題を送信してください。Google+ のページや Twitter で Android Studio 開発チームからの情報を常にチェックしてください。