AttributionSource 類別

定義

[Android.Runtime.Register("android/content/AttributionSource", ApiSince=31, DoNotGenerateAcw=true)]
public sealed class AttributionSource : Java.Lang.Object, Android.OS.IParcelable, IDisposable

[<Android.Runtime.Register("android/content/AttributionSource", ApiSince=31, DoNotGenerateAcw=true)>]
type AttributionSource = class
    inherit Object
    interface IParcelable
    interface IJavaObject
    interface IDisposable
    interface IJavaPeerable

繼承

Object

JavaObject

Object

AttributionSource

屬性

RegisterAttribute

實作

IParcelable IJavaObject IJavaPeerable IDisposable

備註

此類別代表應歸屬存取權限保護資料的來源。 歸因來源可以串連起來，表示受保護資料會經過多個應用程式的情況。 例如，應用程式 A 可能會要求應用程式 B 提供聯絡人，而應用程式 B 又可能向應用程式 C 詢問聯絡人。 此時歸因鏈為 A -> B -> C，資料流為 C -> B -> A。使用歸因來源機制有兩個主要好處：如果你代表呼叫應用程式存取私人資料並回傳，避免對呼叫應用程式進行明確的權限檢查;避免雙重資料存取責怪，這通常是在你檢查呼叫應用程式的權限時，以及存取這些權限背後的資料時發生的（針對執行時權限）。 而且如果沒有明確怪罪來電者，資料存取會算進你的應用程式，而不是上一個應用程式，因為你的資料只是代理。

每個都有 Context 歸屬來源，你可以透過 Context#getAttributionSource() 自我表示來獲得，這是一條一連串的。 你可以將工作歸因於另一個應用程式，或更精確地說，將資料流經一連串應用程式，透過 Context#createContext( ContextParams) 指定下一個應用程式的歸因來源，以接收你所存取 AttributionSource.Builder#setNext( AttributionSource)的受保護資料。 建立這條歸因鏈確保資料來源會在釋出資料前檢查歸因鏈中的每個應用程式是否都有存取權限。 如果資料受到敏感權限（例如危險權限），資料來源也會適當記錄該資料是否被序列中的應用程式存取。 同樣地，如果你是代表另一個應用程式存取資料，例如語音辨識器使用麥克風來識別來電應用程式，這很有用。

你可以建立一個歸因鏈，連結你和其他任何應用程式，無需驗證，因為這已經 android.app.AppOpsManager 透過 API 提供。 這支援處理無法取得呼叫者歸因來源且可直接使用 AttributionSource.Builder API 的情況。 然而，如果資料流經超過兩個應用程式（比你為呼叫者存取的資料還多），你需要有一個指向 AttributionSource 呼叫應用程式上下文的句柄，才能建立歸因上下文。 這表示你要麼需要讓對方應用程式有 API 來傳送其歸因來源，要麼使用平台 API 來傳送呼叫者的歸因來源。

你無法在沒有所有應用程式參與歸因鏈的情況下（上述特殊情況除外）偽造歸因鏈。 要建立一個可信的歸因來源，你需要建立一個歸因上下文，指向由它所引用的應用程式明確建立的歸因來源，且遞迴式。

由於建立歸因上下文會檢查歸因鏈中所有應用程式的權限，因此在存取權限保護的 API 時，你必須預期會遇到安全例外，因為鏈中某些應用程式可能沒有權限。

Java 文件 android.content.AttributionSource。

本頁部分內容為基於 Open Source Project 所創建與分享的作品，並依授權條款所描述的使用進行修改。