8 月 16 日、Google は新しい Android 13 システムのソース コードが Android Open Source Project (AOSP) にアップロードされたことを発表し、Android 13 が正式にリリースされました。Android 13 の最初のプレビュー バージョンが 2022 年 2 月にリリースされて以来、7 か月間のテストと最適化を経て、Android 13 の公式バージョンがついに登場しました。Android 13 は依然として個人のプライバシー保護とセキュリティに重点を置いており、Internet of Everything の時代における画面適応やバッテリー使用の最適化などの関連技術開発機能を提供します。
興味のある開発者は、公式 Web サイトにログオンして、テストと学習用のソース コードをダウンロードできます: https://developer.android.google.cn/about/versions/13
Getui サービスの開発者は、長年にわたって業界の開発動向に細心の注意を払い、フォローアップしてきました。Android 13 の正式版がリリースされた後、エミュレータを使用して調査と適応テストを実施しました。この記事では、開発者が新しい Android システムの適応をすばやく開始して完了するのに役立つように、パーミッションの変更、システムの最適化、および機能の更新に関する Android 13 の新機能について説明します。
権限の変更
1.届出機関
通知バーのメッセージは、アプリがユーザーと通信するための効果的なチャネルでした。Android 13 より前は、アプリは NotificationManager を使用して通知バー メッセージをエンド ユーザーにプッシュするだけで済みました。Android 13 では、新しいランタイム通知パーミッション POST_NOTIFICATIONS が導入されています。この点で、アプリ開発者はそれに集中する必要があります。
この権限でプッシュがテストされており、概要は次のとおりです。
1. まず、TargetSdk<33 の場合を見てください。
下の図に示すように、アプリが通知バー機能を使用すると、システムは自動的に認証ポップアップ ウィンドウをポップアップ表示します。
ユーザーが [許可] をクリックすると、アプリは通常どおりメッセージをユーザーにプッシュできます。
2. TargetSdk == 33 の状況をもう一度見てください。
開発者は、AndroidManifest.xml で POST_NOTIFICATIONS パーミッションを宣言する必要があります。また、通知バーのプッシュ機能を使用する場合は、コードでランタイム パーミッションを申請する必要があります。
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
package="com.gt.demo.mubai.push">
<uses-permission android:name="android.permission.POST_NOTIFICATIONS"/>
</manifest>
requestPermissions(new String[]{“android.permission.POST_NOTIFICATIONS”})复制
上記は、ユーザーが「許可」App Push をクリックした場合です。もちろん、ユーザーが「許可しない」をクリックすることも可能です。承認がユーザーによって拒否されると、システムは次回許可申請のポップアップ ウィンドウを表示しないことに注意してください。
アプリが引き続き重要なメッセージ (メジャー バージョンの更新など) をユーザーにプッシュする必要がある場合は、ユーザーが設定インターフェイスに移動して通知許可を有効にするようにガイドする必要があります。コードは以下のように表示されます:
private void jumpNotificationSetting() {
final ApplicationInfo applicationInfo = getApplicationInfo();
try {
Intent intent = new Intent();
intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
intent.setAction("android.settings.APP_NOTIFICATION_SETTINGS");
intent.putExtra("app_package", applicationInfo.packageName);
intent.putExtra("android.provider.extra.APP_PACKAGE", applicationInfo.packageName);
intent.putExtra("app_uid", applicationInfo.uid);
startActivity(intent);
} catch (Throwable t) {
t.printStackTrace();
Intent intent = new Intent();
intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
intent.setAction("android.settings.APPLICATION_DETAILS_SETTINGS");
intent.setData(Uri.fromParts("package", applicationInfo.packageName, null));
startActivity(intent);
}
}复制
★リマインダー:
ユーザーが通知を有効にしているかどうかをアプリが確認したい場合は、 NotificationManager.areNotificationsEnabled() を呼び出して判断できます。
さらに、「許可する」と「許可しない」の 2 つの選択肢に加えて、ユーザーは許可申請ダイアログ ボックスから離れてスワイプすることもできます (ユーザーはダイアログから離れてスワイプします)、つまり、ユーザーは許可することを選択しません (または許可しない)。次に、アプリが通知バー メッセージをプッシュすると、システムはユーザー認証ポップアップ ウィンドウを再度ポップアップ表示します。
★つぶやき:
Android 13 の通知許可の変更により、エンド ユーザー エクスペリエンスが大幅に向上します。ユーザーは、無効な情報による頻繁な中断を減らすために、アプリによってプッシュされる通知バー メッセージを受け入れるかどうかを個別に選択できます。
GeTui はメッセージ プッシュ サービスとして始まり、エンド ユーザーにより良いエクスペリエンスを提供するために、適切なタイミング、適切な場所、適切なシーンで適切なコンテンツを適切な人にプッシュすることを強調して、常にグリーン プッシュを提唱してきました。
2. WiFi パーミッションの変更
Android 13 での WiFi パーミッションの変更も大きな焦点です。現在の Internet of Everything では、さまざまなスマート ホーム/スマート ウェアラブル デバイスがほとんど WiFi を介して相互接続されているため、この種のアプリ開発者はコンテンツのこの部分にもっと注意を払う必要があります。
以前のバージョンの Android システムでは、アプリが WiFi 関連の機能を使用する場合、以下に示すように、ACCESS_FINE_LOCATION、つまり位置の許可を申請する必要があります。
▲画像はAndroid13公式サイトより
過剰なアプリ クレームを回避し、エンド ユーザーのプライバシーをより適切に保護するために、Android 13 では WiFi のアクセス許可を位置情報のアクセス許可から分離し、新しいランタイム アクセス許可である NEARBY_WIFI_DEVICES を導入しています。
アプリが WiFi 関連の API のみを使用する必要があり、getScanResults() や startScan() などの位置関連の API を使用する必要がない場合、アプリ開発者は新しい NEARBY_WIFI_DEVICES 権限に切り替えることをお勧めします。
新しい WiFi 許可操作メカニズム:
▲画像はAndroid13公式サイトより
パーミッションの使用と適応:
開発者は、アプリケーション (targetSdk == 33) がWiFi 情報に基づいてデバイスの物理的な位置情報を取得しないと宣言した場合、ACCESS_FINE_LOCATION パーミッションを宣言する必要がなくなることに注意してください。
さらに、アプリがAndroid 13 で WiFi API のみを使用し、位置情報を使用しない場合、開発者は AndroidManifest.xml に NEARBY_WIFI_DEVICES パーミッションを追加し、usesPermissionFlags 属性を neverForLocation に設定し、maxSdkVersion="32" 制限を追加できます。 ACCESS_FINE_LOCATION パーミッション. コードは以下のように表示されます:
<manifest ...>
<uses-permission android:name="android.permission.NEARBY_WIFI_DEVICES"
android:usesPermissionFlags="neverForLocation"/>
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"
android:maxSdkVersion="32" />
</manifest>复制
3.細分化されたメディアの権利
Android 13 では、通知権限と WiFi 権限の更新に加えて、ローカル データ アクセス権限がさらに洗練されています。
Android13 では、以下に示すように、READ_EXTERNAL_STORAGE および WRITE_EXTERNAL_STORAGE パーミッションが READ_MEDIA_IMAGES、READ_MEDIA_VIDEO、および READ_MEDIA_AUDIO に細分化されています。
▲画像はAndroid13公式サイトより
このプッシュでは、android.permission.READ.MEDIA_IMAGES を使用して新しい権限をテストします。
READ_MEDIA_IMAGES のみ、READ_MEDIA_VIDEO のみ、および READ_MEDIA_IMAGES と READ_MEDIA_VIDEO を同時にリクエストすると、システムは1 つの認証ポップアップ ウィンドウしか表示しないことがわかりました。
また、アプリ (targetSdk == 33) が読み取り権限を申請した場合、アプリには書き込み権限もあり、WRITE_EXTERNAL_STORAGE 権限を宣言する必要はありません。コードは次のとおりです。
<manifest ...>
<uses-permission android:name="android.permission.READ_MEDIA_IMAGES" />
<uses-permission android:name="android.permission.READ_MEDIA_AUDIO" />
<uses-permission android:name="android.permission.READ_MEDIA_VIDEO" />
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"
android:maxSdkVersion="32" />
</manifest>复制
4.正確な目覚まし時計の許可
システムリソースを節約するために、Android 12 では「目覚まし時計とリマインダー」機能の認可管理に SCHEDULE_EXACT_ALARM パーミッションが導入されています。Android 13 では、新しい目覚まし時計のアクセス許可 USE_EXACT_ALARM が導入されています。
Android 12 の SCHEDULE_EXACT_ALARM パーミッションとは異なり、アプリが新しいパーミッション USE_EXACT_ALARM を申請した場合、ユーザーは設定ページで承認をオフにすることはできません。
スケジュール管理や時間管理などのアプリでは、Android 13 で導入された USE_EXACT_ALARM パーミッションが一定の利便性をもたらします。Android 12 の SCHEDULE_EXACT_ALARM パーミッションと比較して、新しいパーミッションを使用するアプリは、承認のためにユーザーを頻繁に邪魔する必要がなくなり、目覚まし時計やスケジュール リマインダーなどのサービスをより効率的にユーザーに提供できます。
ただし、新しい権限の悪用を防ぐために、Google Play は厳格なリスティング レビュー メカニズムを設定しました。開発者は、USE_EXACT_ALARM パーミッションが使用されると、アプリが GooglePlay でリリースされるときに、プラットフォームによって厳密にレビューされることに注意する必要があります。アプリが目覚まし時計、タイマー、カレンダー、その他の種類のアプリケーションに属しているか、アプリケーション マーケットのホワイトリストに含まれていない限り、Google Play はこの権限を使用するアプリケーションの起動を許可しません。
★つぶやき:
わが国でのアプリユーザーの個人的権利と利益の保護が強化され続けているため、その後の国内の携帯電話メーカーとアプリケーション市場はフォローアップし、ユーザーの権利と利益の保護を強化するために対応するレビューメカニズムを確立すると考えられています。アプリの開発者は、関連する開発に引き続き注意を払い、タイムリーに適切な適応を行うことをお勧めします。
5.バックグラウンド センサーのアクセス許可
今日では、生体情報セキュリティも世間の注目の的となっています。エンド ユーザーの個人の生物学的情報をより適切に保護するために、Android 13 には新しいバックグラウンド センサーのアクセス許可が追加されています。
アプリがバックグラウンドで実行されているときに、心拍数、体温、血中酸素飽和度などのセンサー情報を取得する必要がある場合は、既存の BODY_SENSORS パーミッションをユーザーに適用するだけでなく、新しい BODY_SENSORS_BACKGROUND 権限。
要約すると、Android 13 は個人のプライバシー保護を非常に重視し、強化していることがわかります。権限の変更に加えて、Android 13 ではシステムの最適化とコンポーネントの更新も行われ、システムのセキュリティと使いやすさがさらに向上しています。
システムの最適化
1. より安全なシステム コンポーネント
インテントフィルター
以前のバージョンの Android システムでは、開発者は android:exported を true に設定するだけで、アプリケーション全体で明示的にアクティビティとサービスを開始できました。インテント フィルターのアクションまたはタイプが一致しなくても、開始できます。
上記の脆弱性を回避するために、Android 13 ではインテント フィルターのマッチング フィルタリング ロジックが強化されました。受信側の targetSdk == 33 の場合、intent-filter が一致してヒットすると、送信側の targetSdk のバージョンに関係なくインテントが有効になります。
★リマインダー:
次の状況では、intent-filter のマッチング フィルタリング ロジックに従う必要はありません。
-
コンポーネントが宣言されていません
-
同じアプリ内のインテント
-
システムまたはルート プロセスによって発行されたインテント
ブロードキャストレシーバー
以前の Android システムでは、アプリケーションによって動的に登録された BroadcastReceiver ブロードキャスト レシーバーは、任意のアプリケーションによって送信されたブロードキャストを受信します (レシーバーがアプリケーション署名許可保護を使用しない限り)。これにより、動的に登録されたブロードキャスト レシーバーがセキュリティ リスクになります。
Android13 では、アプリケーションによって動的に登録されたブロードキャスト レシーバーが、他のアプリケーションが にアクセスできるかどうか、つまり、他のアプリケーションがブロードキャストを送信できるかどうかを目立つ方法で示す必要があります。そうしないと、システムは動的登録中にセキュリティ例外 (SecurityException) をスローします。
現在、この拡張機能はデフォルトでは有効になりません。開発者は、DYNAMIC_RECEIVER_EXPLICIT_EXPORT_REQUIRED 互換性フレームワークを有効にし、ブロードキャストを動的に登録するときに他のアプリケーションからのブロードキャストを受け入れるかどうかを指定する必要があります。
context.registerReceiver(receiver, intentFilter, RECEIVER_EXPORTED)
context.registerReceiver(receiver, intentFilter, RECEIVER_NOT_EXPORTED)复制
★リマインダー:
システム ブロードキャストは、RECEIVER_NOT_EXPORTED の影響を受けません。
2 つ目は、フロント デスク サービス (FGS) タスク マネージャーです。
Android 13 では、フォアグラウンド サービス (FGS) のタスク マネージャー機能も追加されています。
下の図に示すように、ユーザーはドロップダウン通知バーでフォアグラウンド サービスとアプリケーションを直接閉じることができます。
さらに、アプリがフォアグラウンド サービスを長時間(24 時間のうち少なくとも 20 時間)実行していることをシステムが検出すると、次の内容のリマインダー通知がユーザーに送信されます。
APP が長時間バックグラウンドで実行されています。タップして確認します。
次のいずれかの条件が満たされた場合、通知は表示されないことに注意してください。
-
フォアグラウンド サービスに関連する通知が送信されました。つまり、ユーザーは以前のリマインダー通知を閉じていません。
-
フォアグラウンド サービスのタイプは FOREGROUND_SERVICE_TYPE_MEDIA_PLAYBACK または FOREGROUND_SERVICE_TYPE_LOCATION です。
★リマインダー:
この通知がアプリに対して既に表示されている場合、少なくとも 30 日間は再度表示されません。さらに、システムレベルのアプリケーションやセキュリティ アプリケーション (android.app.role.EMERGENCY ロールを持つアプリケーションなど) などのフォアグラウンド サービスは、FGS タスク マネージャーに表示されません。
3.届出権限
Android9 では、アプリケーションの使用時間と頻度に応じて優先度の異なる 5 つのストレージ パーティションにアプリケーションを動的に割り当て、異なるストレージ パーティション内のアプリケーションに異なるレベルのアプリケーション リソース制限を課す、アプリケーション スタンバイ ストレージ パーティション機能が導入されています。
次のように、ストレージ パーティションは優先度の高いものから低いものへと並べ替えられます。優先度が低いほど、パーティション内のアプリに対する制限が多くなります。
-
アクティブ: アプリは現在使用中、または最近使用されました。
-
ワーキング セット: アプリは定期的に使用されます。
-
頻繁に使用: アプリは頻繁に使用されますが、毎日ではありません。
-
ほとんど使用されていない: アプリはあまり使用されていません。
-
制限あり: アプリが大量のシステム リソースを消費するか、不適切な動作を示します (Android 11 で導入)。
このうち、「制限あり」状態の申請には、以下の制限が課せられます。
-
フォアグラウンド サービスを開始できません。
-
既存のフォアグラウンド サービスはフォアグラウンドから削除されます。
-
アラームはトリガーされません。
-
ジョブは実行されません。
Android9 アプリケーション スタンバイ ストレージ パーティション機能に基づいて、Android13 はバッテリー リソース戦略を最適化し、デバイスのバッテリー寿命を延ばし、エンド ユーザー エクスペリエンスを向上させます。
まず、Android13 では以下のルールが追加され、対応するルールを満たすアプリケーションは「制限付き」のストレージ パーティションに入ります(デバイスの電源がオフになっている時間は対話制限にカウントされません)。
-
ユーザーは 8 日間アプリを操作していません。
-
アプリケーションが 1 日にブロードキャストまたはバインドされたサービスを呼び出す回数が多すぎます。
-
アプリは 1 日で多くのバッテリー電力を消費します。しきい値はデバイスによって異なります。
次に、Android13 では、「制限付き」ストレージ パーティションの適用にも制限が追加されています。
-
アプリケーションは、BOOT_COMPLETED、LOCKED_BOOT_COMPLETED ブロードキャストを受信しません
4.非 SDK インターフェース制限の更新
Android 13 では、一部の非 SDK インターフェースが制限されています (また、一部の制限に対する代替手段が提供されています)。開発者は、アップグレード時にアプリが制限付きの非 SDK インターフェースを使用するかどうかを明確にする必要があります。
Android13 で制限された非 SDK インターフェース参照:
Landroid/app/Activity;->setDisablePreviewScreenshots(Z)V # Use setRecentsScreenshotEnabled() instead.
Landroid/os/PowerManager;->isLightDeviceIdleMode()Z # Use isDeviceLightIdleMode() instead.
Landroid/os/Process;->setArgV0(Ljava/lang/String;)V # In general, do not try to change the process name. If you must change the process name (for instance, for debugging), you can use pthread_setname_np() instead, though be aware that doing this might confuse the system.
Landroid/view/accessibility/AccessibilityInteractionClient;->clearCache(I)V # Use android.accessibilityservice.AccessibilityService#clearCache() instead.复制
機能更新
ユーザー エクスペリエンスの向上は、常に Android システム アップデートの焦点でした。Android 13では、主にクリップボード、画面適応、UI表示などの機能更新が行われています。
1.まな板
まずクリップボードを見てください。誰もがクリップボードを使用したことがあると思います。ページ上のコンテンツをすばやくコピーできるため、コンテンツを編集および変更するのに便利です。
ただし、クリップボード機能には常に危険が隠されています。つまり、クリップボードによってコピーされたコンテンツに機密情報が含まれている可能性があります。クリップボードのプライベート コンテンツ (携帯電話番号、電子メール、アカウント パスワードなど) の漏洩を防ぐために、Android 13 ではクリップボード機能が更新されました。
以下の図に示すように、Android13 のクリップボード機能は 2 つのステップで使用されます。
-
コンテンツが正常にコピーされたことを確認します。
-
コピーされたコンテンツのプレビューを提供します。
さらに、Android 13 では、ユーザーが機密情報をクリップボードに隠すことができる感度低下機能も提供され、利便性とセキュリティの両方を実現しています。
2.タブレットと大画面のサポートの向上
タブレット コンピューター、大型の車の画面、およびスマート TV 画面の幅広いアプリケーションにより、ユーザーの端末シナリオはますます多様化しています。さまざまな端末のユーザーに常に美しくスムーズな体験を提供するにはどうすればよいですか? Android 13 では、これに対するサポートが向上し、システム UI と大画面での分割画面表示が更新されます。
下の図に示すように、大画面では、Android 13 は同じ画面でのさまざまな機能モジュールの表示をサポートしているため、大画面の利点を最大限に活用できます。
▲Android 13のシステムでは、「クイック設定」セクションと「通知バー」セクションを同じ画面に配置できます。
3. Jetpack ウィンドウ マネージャー
さらに、 Android 13は、大画面の表示スペースを最大限に活用するために、ユーザーが一度に大画面に複数のアクティビティを表示することもサポートしています。
開発者は、XML 構成ファイルを作成するか、Jetpack WindowManager API 呼び出しを行って、アプリが複数のアクティビティを同じ画面に表示するための特定の方法 (横に並べたり、積み重ねたりするなど) を決定できます。
▲たとえば、分割タスク ウィンドウの形式で 1 つの画面に 2 つのアクティビティを表示します。
4. 互換性サポートの向上
Android 13 は、大画面に適応していないアプリに対して、より使いやすく安定した互換性サポートも提供するため、これらのアプリは、エンド ユーザーのエクスペリエンスに影響を与えることなく、デフォルトで快適で美しい UI 表示を実現できます。次の図:
▲画像はAndroid13公式サイトより
要約:
過去 2 年間の Android システム アップデートを通じて、Google が Android システムに大幅な変更を加えるのではなく、ユーザー エクスペリエンス、プライバシー保護、システム セキュリティ、およびコンポーネントの最適化に多大な努力を払っていることがわかります。
Android 13 のその他の更新ポイントについては、開発者は Android 13 の公式 Web サイトにアクセスして詳細を確認できます: https://developer.android.google.cn/about/versions/13
新しいシステムの適応と Android の開発について、より詳細なやり取りが必要な場合は、@加推技术サポートを追加して、お問い合わせください。
今後、Getui は引き続き Android システムと業界の発展に注意を払い、モバイル開発技術について開発者とコミュニケーションを取り、新しいモバイル インターネット エコシステムを共同で構築していきます。