真面目なブログはこっち 👉 blog.s64.jp

Android Developers Blog 2021年5月6日の記事を読む

たぶんもうすこし待てば日本語版記事がオフィシャルに出るんじゃないかな〜。それまでのつなぎ。
認識を恣意的に歪めうるので、あくまで読み進める上でのガイドとして。

android-developers.googleblog.com

ざっくり

  • safety section をGoogle Playに増やすよ
  • アプリによる情報収集, 共有, (セキュアな)保管、そのほかプライバシー諸々について表明するセクションだよ
  • 大きな変化になりうるので、事前にアナウンスしたよ

タイムライン

  • 今回(Q2 '21)はpre-announcementだよ
  • Q3 '21にポリシーを出すよ
  • Q4 '21に開発者がGoogle Play Consoleで入力できるようになるよ
  • Q1 '22にアプリのユーザがこの情報を見れるようになるよ
  • Q2 '22までに新規・既存アプリ共に対応が済んでる必要があるよ

こういう情報を提示してほしいよ

  • データの暗号化など、情報の保全に必要な措置を取っている(取っているか?)
  • ファミリーポリシーに準拠している(準拠しているか?)
  • アプリが機能する為に収集する情報は何か、またその提供をユーザがオプトアウトできるか

具体的に、このへんを取る旨を明示してほしいよ

  • 収集するデータの種類
    • 位置情報の取得
    • 連絡先一覧
    • 氏名やメールアドレス
    • 写真、ビデオ、音声ファイル
    • ストレージ上の各種ファイル
  • 収集したデータの使用方法
    • アプリの機能において必須の情報か
    • パーソナライズで利用している情報か

こういう仕様になるよ

  • 当該のセクションは独立した第三者(independent third-party)により保証される

→ アプリの審査において申告内容に虚偽がないかチェックが入るのかな?

こういう要件が増えるよ

  • ユーザがアプリをアンインストールした場合、ユーザは各種情報の削除を求められる

→ これ、バックエンドにあるデータとかも消すってことだと思うけどどうなるんだろ?

SDKMANでOracle JDKなどを管理させる (on macOS)

SDKMANはそれ自身で各種JDKディストリビューションをダウンロード、インストール、管理できる。
しかしOracle JDKなどSDKMAN自体は管理機能を持っていないJDKもある。

これらをSDKMANで管理させる手順。

1. 普通にインストールする。

Oracleのサイトからダウンロードして、普通にインストールする。

2. インストール先を特定する。

たとえばmacOSの場合は /Library/Java/JavaVirtualMachines にある。具体的には、

  • /Library/Java/JavaVirtualMachines/jdk-11.0.10.jdk
  • /Library/Java/JavaVirtualMachines/jdk-14.0.1.jdk

のようなパスにある。

3. SDKMANの管理下に置く

2で特定したディレクトリ配下の /Contents/Home をSDKMANに渡す。今回はJDK 11を例に取る。
またidentifierも一緒に与える。たとえば 11.0.10-oracle のような形式。

sdk install java 11.0.10-oracle /Library/Java/JavaVirtualMachines/jdk-11.0.10.jdk/Contents/Home

4. 必要に応じてdefaultに設定する

さきほど設定したidentifierを渡せばよい。

sdk default java 11.0.10-oracle

あわせてよみたい

Android StudioやIntelliJ IDEAでOracle JDKを使いたい、かつSDKMANの管理配下から取りたい、という場合は下記の記事が参考になるはず。

blog.s64.jp

常にdefaultとして設定したJDKを参照するようにしたければ、JDK Locationとして $HOME/.sdkman/candidates/java/current を設定するという荒業もある。

JCenter / Bintray 終了による最悪のパターン妄想

下記のような記事を書いていて、

blog.s64.jp

恐怖を煽りすぎてもよくないから本体には書くべきでないと思ったけど こういうこともあるよね、みたいなパターンをいくつか思いついてしまった為ここに書いていく。

みんながみんなGitHub Packages等に移転したら?

BintrayやGitHub Packagesは、利用者ごとにリポジトリの名前空間を分けている。そのため別のユーザが作成したリポジトリからライブラリを参照する場合、それらは都度都度参照元のリポジトリとして書き足していくことになる。

もしあらゆるライブラリ作者がそうしたサービスに移転した場合どうなるか?当然参照先リポジトリ一覧はライブラリの数だけ記述が増える。
参照先リポジトリが増えることには弊害があって、

  1. URLが異なれば同じartifact idを持つライブラリを公開できる(場合が多い)。みんな好きにやったら衝突してしまうのでは?
  2. Gradle等の場合、依存関係は定義順に上から手繰っていく。増えれば増えるほど404でフォールスルーしていくのでHTTPのリクエスト数が増えていき、依存関係解決に掛かるコストがどんどん増えていくのでは?

という懸念を持っている。
2の話については下記の記事で書いている。

blog.s64.jp

古いバージョンは移転せず新しいバージョンだけ移転されたら?

今Bintray上でホストされているバイナリをすべて移転してさえくれれば、長期間メンテナンスされていないアプリでもリポジトリだけ書き換えればうまいこと動くだろう。
しかしもし古いバージョンは移転せず最近のバージョンのみ移転された場合は?そしてその間に破壊的変更があった場合には?

もしかしたら、リポジトリの移行だけでなく最新バージョンへの追従とそのための動作確認、のようなタスクが急遽入ってくるかもしれない。
ただ、これは珍しいケースになりそうだ。

ライブラリがメンテされていなかったら?

JCenterやBintrayでホストされているライブラリというのはビルド済のバイナリなので、当然ソースコードがメンテナンスされていなくても基本的にはダウンロードできる。
しかしもし随分昔に公開されたまま最近はメンテナンスされていなかったら?そのメンテナが移行作業を行わなかったら?

これはそのアプリの性質によってはかなりの割合で起きそうだ。年単位でメンテナンスされておらず移行作業もされそうにないライブラリはかなりある。もしそのようなライブラリを使用していた場合、最悪関連するコードを全部剥がして再実装することになるかもしれない。

最悪の場合を想定した対策

現行の依存関係すべてを解決し、jarファイル(aarファイル)をキャッシュしておいたほうがいいかもしれない。
まさにSonatype Nexusなどはこれに相当する機能を持っていて、Nexusがプロキシとなり各リポジトリから取得したアーティファクトをキャッシュできた記憶がある。


追記。そのほか興味深い指摘を頂いているのでここに列挙させていただく。

法人成りした場合のはてなブログ利用まわりメモ

問い合わせした回答のメモ

  • はてなブログ法人利用ガイドラインが示しているのは、法人名義での利用について
  • 仮に所有 & 支払をしているのが法人であっても、少なくとも創業2期目の 合同会社キガニックス のような個人企業規模かつ法人名ではない(あくまで代表個人としての)ブログであれば、個人向けプラン(はてなブログPro)のままでOK
  • 「はてなブログ for DevBlog」は技術関連の記事以外の発信には使えない為、法人名義で技術情報記事以外を掲載する場合には「はてなブログBusiness」かそれ以上のプランが必須になる
  • /about で表示されるブログプロフィール上のマーク(バッジ)はそのブログのプランを表示していて、はてなブログProの場合は PRO、はてなブログ for DevBlogの場合は DEVBLOG と表示される
  • はてなブログ for DevBlogの機能は はてなブログProと同等

Androidにおけるprotobufのjavaliteについてメモ

直接仕事に関係はないけど、急に情報を集める必要が出てきた為 雑なメモとして。実際に手元で動かしているわけではないので、少なからず誤った記述をしていそう。

AndroidでのProtocol Buffers利用

Androidでは標準ビルドツールとしてGradleを使うので、protobuf-gradle-plugin を導入する。
これはローカルにあるprotocバイナリとのブリッジが主な仕事で、有効にするとGradleプロジェクト内のsourceSetに配置した .proto をJavaクラスとしてコンパイル可能になる。
protocのバイナリをローカルに入れてない場合も考慮して、protobuf.protoc.artifact = 'com.google.protobuf:protoc:3.0.0' などとしてMaven上のprotocを指定すると良い。

Java Lite Runtime

Androidはご存知のとおり一般的なJVMとは異なるRuntimeになっており、これをGoogleのProtobufチームは「制約のある実行環境」と呼んでいるらしい。このような環境を考慮して設計された "Lite" と呼ばれるモードがある。

Liteではprotocによる単なるコンパイルでのJavaクラス吐き出しではなく、

  • Android Runtime等の制約ある環境でも使用可能なJava APIのみの使用
  • 共通ロジックを外部ライブラリへ切り出すことによる省サイズ化

などが行われたものになる。現在この機能は protoc 自体に搭載されているため、Gradleプロジェクトの設定レベルでフラグを立てることで有効化できる。ただし上記のとおり外部のライブラリへ共通ロジックが切り出されている為、その記述は別途必要になる。

// https://github.com/google/protobuf-gradle-plugin#default-outputs

def protobufVersion = '3.8.0'

dependencies {
  implementation "com.google.protobuf:protobuf-javalite:${protobufVersion}"
}

protobuf {
  protoc {
    artifact = "com.google.protobuf:protoc:${protobufVersion}"
  }
  generateProtoTasks {
    all().each { task ->
      task.builtins {
        java {
          option "lite"
        }
      }
    }
  }
}

ポイントは「現在この機能は protoc 自体に搭載されている」「外部のライブラリへ共通ロジックが切り出されている」の2点。protobuf-javalite はあくまでも protoc のLite機能用の内部APIが切り出されたライブラリという位置付けである為、protocの機能アップデート等によって決められたバージョニング規則がそのまま protobuf-javalite にも設定される。両者は一体となって利用される前提である為、常に同じものが設定されなければいけない。
もしこれが異なるバージョンになった場合、protocのLiteモードで出力されたJavaクラスと、それが参照する protobuf-javalite のAPIに齟齬が起きClassNotFound等の例外が発生する可能性がある。


なお、この protobuf-javalite というライブラリは以前 protobuf-lite というartifactだった。

<artifactId>protobuf-lite</artifactId>

https://github.com/protocolbuffers/protobuf/blob/ca21b28287871660057a2b8bada2c044b6b3075d/java/lite/pom.xml#L12

これが2016年頃のリリース以来長いことアップデートされていなかったのだが、2019年6月頃にリリースされた 3.8.x の時に protobuf-javalite へと変更されている。

<artifactId>protobuf-javalite</artifactId>

https://github.com/protocolbuffers/protobuf/blob/815ff7e1fb2d417d5aebcbf5fc46e626b18dc834/java/lite/pom.xml#L12

即ち両者は単なるアップグレードであり、protobuf-lite -> protobuf-javalite という流れで移行されることが理想である。

またこの旧バージョンではprotoc内にliteのモードが同梱されていなかったため、codegenとして com.google.protobuf:protoc-gen-javalite:xxx を指定していた。

2021年賀状を住所を知らないネットの友達に自作デザインで送る

昨年のこれに引き続き、2021年版です。

h.s64.jp

昨年は日本郵便のはがきデザインキットを使ったが、今年からWeb版が提供されず、またSNS等を経由した送付機能も無いため何かしら別のツールへ移行が必要。

2021年(2020年末の投函分)の場合、富士フイルムイメージングシステムズ株式会社の提供するウェブポ 年賀状2021を使えばいける。ハガキを用意しなくても、クレジットカードさえあれば印刷から投函までぜんぶやってくれるので便利。

1. ウェブポ会員としてログイン

なければ作る。Webサイト右上の「未ログイン」と表示されているところから「ログイン」へ進めばいける。

2. 全面写真レイアウトで作る

ログインしたらウェブポトップへ戻る。今回はオリジナルのデザインにしたいので、上部メニューの「年賀状デザイン」内から「全面写真」を選ぶ。もちろん特段こだわりがないだとか、気に入ったデザインがあるのなら他のレイアウトを選んでもよい。その場合、レイアウトによっては写真や文章を挿入できる。

Image from Gyazo


Image from Gyazo

3. 用紙を選ぶ

フチ無しの場合はフジカラー仕上げ、フチありの場合は印刷仕上げを選ぶ。
フジカラー仕上げは写真用紙に印刷され、郵便はがきに貼り合わされる為すこし厚みが出る。印刷仕上げは直接郵便はがきに印刷されるもの。

webpo.jp

Image from Gyazo

4. 入稿データを作る

入稿データと言うけど、ただの画像ファイルでOK。ウェブポのFAQ内に「自分で作成したデータを最適に印刷するためには、どのくらいの大きさ・dpiの写真を用意すればよいでしょうか?」としてかなり詳しく書いてあるのでそこを読むとよい。

webpo.jp

ポイントは、

  • jpg推奨であること
  • 300dpi程度推奨であること
  • フチありの場合は、1063x1630 が印刷可能領域ジャストサイズであること
  • フチなしの場合、1181x1748が推奨サイズであること。また塗り足し領域が82px程度であること

の4点あたり。

※ 2020年12月14日追記: 推奨サイズで入稿しても "ぴったり" 表示にはならないので、拡大縮小を駆使し、塗り足しを意識して作成する必要アリ

5. エディタにアップロードする

拡大縮小, 回転などができる。はがきデザインキットと違い、写真補正機能はない。
完了したら、右下のすすむを押下する。

6. あいさつ文等を追加する

テキストの挿入が可能。はがきデザインキットと違い、スタンプ等の機能はない。
なお、ここで挿入したテキストとは別に、宛先選択後に宛先個別のテキスト挿入が可能。後述。

完了したら、右下のすすむを押下する。

7. 差出人住所を設定する

「差出人住所を印刷しない」にチェックを入れると、自分の住所を晒さなくてもよくなる。

なお、宛先選択後に個別に差出人を差し替えることもできる。また、当該画面で「ウェブポ事務局」を差出人とすることも可能。

8. 保存する / 呼び出す

デザインを保存しておけば急にブラウザが停止してもなんとかなるので、一旦ここでは先に進まず保存しておくとよい。そのまま進んでもよい。なお、注文完了時に保存済デザインは破棄される為、同じデザインを呼び出すことはできない。

もしここで保存後中断した場合、Webサイト上部の「ログイン中」内にある「編集再開」からデザインを呼び出すことができる。

Image from Gyazo

複数デザインを保存しておく機能はないように見える。

9. 配送先を指定する

すすむを押下すると、「あて名を印刷する」「あて名を印刷しない」の選択肢が表示されるので、今回は前者で進む。

相手の住所がわかっていれば、ここで「住所を入力」をクリックし必要事項を入力すればいい。プリントから投函まで自動で行われる。
今回はネットの友達宛なのだが、ここで昨年同様2通りの方法がある。どちらの場合も自分には相手の氏名や住所が見えることはなく、相手側の個人情報が割れることはない。

  1. 住所を知らない相手に、どうして年賀状が届くのですか?

  2. ウェブポではメールアドレスやTwitter IDをあて先として年賀状を郵送することができます。お申し込みの方がご指定の年賀状の受取人様ご自身が、受取先の氏名・住所をウェブポの年賀状受け取り手続き画面に入力していただくことで、その氏名・住所が年賀状に印刷され、直接郵送されます。その過程で受取人様の氏名・住所が差出人様に知らされることはありません。

https://webpo.jp/faq/webpo.html

相手にTwitterのDMが送れる場合

「その他サービスから」「Twitter」をクリックし、自分のTwitterアカウントと連携する。相互フォロー中のアカウント一覧が表示される為、選択し決定する。
決定後に「あて先リスト」には表示されないが、正常に選択はされている模様。すすむを押下し差出人情報設定画面に進めば、期待どおりTwitterアカウントが並ぶ。

※ なお、差出人情報設定画面から「もどる」を押下すると、あて先リストの表示が正常になる。不具合らしい。

実際に送られるDMは下記のようなもの。

Image from Gyazo

実際に受け取る際は、URLをクリック後Twitterログインが求められる。そのためURLをシェアして誰かへ転送、のようなことはできない。

相手のメールアドレスがわかる場合

「メールアドレスから」「メールアドレスを入力」をクリックすると、メールアドレスを入力できる。
Google Contactsを活用しているなら「その他サービスから」「Gmail」よりGoogleアカウント連携をすると、Google Contacs内のメールアドレスが列挙される。

なお、既に住所録へメールアドレスを入力している場合は「住所録から選ぶ」をクリックし検索することができる。

メールでの送信が含まれる場合、差出人名義の入力が求められる為注意。この内容は受取確認メールの件名などで使用される。実際に送られるのは下記のようなもの。

Image from Gyazo

※ 住所もTwitterもメールアドレスもわからないけど個別連絡が取れる場合

昨年同様、今年も似たようなことは実現できる模様。LINEやFacebook Messengerで送るメニューは存在しないため、あくまでアンオフィシャルな使い方になるが、下記の手順で実現できる。

  1. 「メールアドレスで送る」へ進む
  2. 自分が受け取れる形式でメールアドレスを指定する
  3. 受け取ったメール(の専用URL)をコピーする
  4. 相手へ個別メッセージで送る
    • 発行されるURLが個人専用なので、不特定多数が踏める場所には絶対置いてはいけない

この受取手続中にメールアドレスの再認証等は無い為、この手順で受取まで進んでもらうことが可能。筆者はこの方法でLINEおよびInstagram上の友達へ受取依頼を行えた。

メールの全文を送る必要はないので、コピーすべきは下記範囲くらいかなと思う:

  この電子メールでは、送り主の [伏せ字] ([伏せ字]) さまに代わって、
  「ウェブポ事務局」が相手先の方々へ年賀状発送の確認を行なっています。
  なお、年賀状は無料で受け取ることができます。
----------------------------------------------------------------------

[伏せ字]  ([伏せ字]) さま

 こんにちは。ウェブポ事務局です。
 [伏せ字]  ([伏せ字]) さまより、あなた宛の年賀状をお預かりしています。
 下記のURLから、年賀状を受け取る手続きをお願いします。

【年賀状受け取り用URL】

  ▼ページに表示される手順にそって手続きしてください。
  https://webpo.jp/app/#/?a=[伏せ字]&type=[伏せ字]&id=[伏せ字]

  ※年賀状受け取り手続きの有効期限は、 2020年12月[伏せ字]日 までです。 
  ※上記URLには送り主の方の名前とメールアドレスが表示されるので、
    他人やインターネット上に公開されないようご注意ください。
  ※受け取り手続きでご入力いただいた住所等の個人情報は、
    送り主の方に知られることはありません。

10. 差出人情報を設定する

以前のステップで既に設定した差出人住所だが、ここで個別に設定することができる。一部だけ会社名義にしたり、ウェブポ事務局名義にしたり、印刷しないこともできる。

11. 個別あいさつ文の設定をする

希望する場合、以前のステップで挿入したテキストと別で宛先個別でテキストを挿入できる。しないこともできる。

12. 決済をする

メールアドレスないしTwitter経由での送付が含まれる場合、クレジットカード以外の決済手段は使えない。これはオーソリ後の受取意思確認をし、拒否や有効期限切れだった場合にキャンセル処理を行う都合。ネット宛先が含まれない場合、LINE Payやコンビニ払いが選択できる。

以上で手続は終了。

GV-NTX1Aがあれば、Chromecast with Google TVでもテレビが見れる。ただしちょっと制約あり。

2020年11月25日に、GoogleからChromecast with Google TVが発売された。
この製品は、Google製ハードウェアのブランドとして発売されたものとしては2014年11月3日に発売されたNexus Player以来、実に6年ぶりのGoogle TV (旧Android TV) 搭載STBとなる。

...というわけで、今回もmy new gear自慢 兼 ちょっとした検証記事です。

Chromecast with Google TVにはチューナ機能が無い

自分は当時からAndroid TV製品のユーザーで、久しぶりのリファレンス機登場には購入を見送る選択肢はなかった。
しかしここ最近自分が使っていたのはGoogle製ではないサードパーティの製品、具体的にはPIX-SMB400という製品で、これにはテレビチューナ機能がある。そしてChromecast with Google TVには無い。そのためChromecast with Google TVの導入により失われる地上波の視聴手段を確保する必要があった。

なお、現在PIXELAからはPIX-SMB400の後継機としてPIX-SMB100が販売されており、こちらに買い換える選択肢もあった。が、自分がAndroidアプリ開発を仕事としている都合上、どちらかといえばリファレンスに近い製品の方が入手優先順位が高かった。

連携できるチューナの購入

そこで、今回はIO-DATAの販売しているGV-NTX1Aを購入した。この製品は地上/BS/CS受信が可能だが、HDMI出力が無い。リアルタイム視聴 / 録画番組視聴はどう行うかというと、IO-DATAの提供するREC-ON Appを使用する。(もちろんiOS向けにもある)

そしてこのREC-ON AppはGoogle TV (Android TV) にも対応しており、STB上でのリアルタイム視聴を実現可能だ。

Chromecast with Google TVのアドバンテージ

恐らく、最大のメリットはGoogleによって最適化されたランチャーだろう。Googleサービスの利用履歴などを参考に、ユーザへのおすすめコンテンツが最適化され表示される。
今までのAndroid TV製品も、たしかにPlay Servicesを経由してこのような表示を可能にしていた。が、さながらFire TVのようなコンテンツを全面に押し出した表示は真新しさを感じた。

そしてアプリ開発者やGoogle製品のハードユーザであれば、最新のOSがリリースされたらできるだけ早く使いたいものだろう。過去のAndroid TV製品はどうしてもOSアップデートはハードウェアベンダの判断に依存するため、あまりスピーディに提供されているとは言い難かった。この製品はGoogleの判断によって提供されるので、スマートフォンのNexusシリーズやPixelシリーズの実績を考えても、最新のイメージは即座に提供されるだろうと期待できる。

もうひとつ。あまり多くの人は気付かないポイントとして、提供されるアプリの種類が豊富であることも挙げられる。実はAmazon Prime Video アプリは必ずしも全てのAndroid TV製品で利用できるものではなく、自分の使っていたPIX-SMB400ではインストールできなかった。
今回のChromecast with Google TVには、このPrime Videoがプリインストールされている。恐らくGoogleはGoogle TVの市場でのポジションを強化することをビジネス上で重視しており、独自のアライアンス締結を行っているのではと思われる。

ディスアドバンテージもある

1点不便な点として、今回導入したREC-ON AppのGoogle TV (Android TV) 版はあくまでも「レシーバ」であること。テレビ上でチャンネルの選択等はできず、スマートフォン側アプリでチャンネルを選択し、それを当該アプリが起動中のSTBで視聴する、という形になる。
自分の場合はテレビの視聴頻度が極端に低く、あくまでも「インターネット上でコンテンツを発信している人物が地上波にも出る」というような例外的な時のみ... 言ってしまえばGoogle TV (Android TV) 上で視聴可能なメディアをスーパーセットとし、地上波はサブセットのような関係でしかなかった。そのため今回はこれを許容できたが、必ずしも全ての家庭で許容できるものではないだろう。
今回は見送ったが、バッファローからの販売が予告されているnasneの新しいモデルが出た頃には(そして引き続きテレビ向けのAndroidアプリがメンテされるならば)そちらの購入も再度検討して良いだろう。torne mobileアプリはGoogle TV (Android TV) に対応しており、アプリ上でひととおりの操作が可能になっている。

また自分の場合は今まで使っていたSTBとの差異として、Chromecast with Google TVは4Kのサポートに少し不満がある。出力解像度設定としては選択可能なのだが、どうもフルHDの設定ほどスムーズに動作しない。STBとしてのマシンスペックが足りないのだろうか?あらゆる操作が目に見えてカクついていた。