{
	"id": "d05d98b5-fada-4672-8470-121cb0b7e66b",
	"created_at": "2026-04-06T00:21:09.415326Z",
	"updated_at": "2026-04-10T03:21:23.228819Z",
	"deleted_at": null,
	"sha1_hash": "1618bcd261cf90013dec2557f4da02b24cabd7de",
	"title": "Broadcasts overview",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 167561,
	"plain_text": "Broadcasts overview\r\nArchived: 2026-04-05 13:59:52 UTC\r\nAndroid apps send and receive broadcast messages from the Android system and other Android apps, similar to\r\nthe publish-subscribe design pattern. The system and apps typically send broadcasts when certain events occur.\r\nFor example, the Android system sends broadcasts when various system events occur, such as system boot or\r\ndevice charging. Apps also send custom broadcasts, for example, to notify other apps of something that might\r\ninterest them (for example, new data download).\r\nApps can register to receive specific broadcasts. When a broadcast is sent, the system automatically routes\r\nbroadcasts to apps that have subscribed to receive that particular type of broadcast.\r\nGenerally speaking, broadcasts can be used as a messaging system across apps and outside of the normal user\r\nflow. However, you must be careful not to abuse the opportunity to respond to broadcasts and run jobs in the\r\nbackground that can contribute to a slow system performance.\r\nAbout system broadcasts\r\nThe system automatically sends broadcasts when various system events occur, such as when the system switches\r\nin and out of Airplane Mode. All subscribed apps receive these broadcasts.\r\nThe Intent object wraps the broadcast message. The action string identifies the event that occurred, such as\r\nandroid.intent.action.AIRPLANE_MODE . The intent might also include additional information bundled into its\r\nextra field. For example, the Airplane Mode intent includes a boolean extra that indicates whether or not Airplane\r\nMode is on.\r\nFor more information about how to read intents and get the action string from an intent, see Intents and Intent\r\nFilters.\r\nSystem broadcast actions\r\nFor a complete list of system broadcast actions, see the BROADCAST_ACTIONS.TXT file in the Android SDK. Each\r\nbroadcast action has a constant field associated with it. For example, the value of the constant\r\nACTION_AIRPLANE_MODE_CHANGED is android.intent.action.AIRPLANE_MODE . Documentation for each broadcast\r\naction is available in its associated constant field.\r\nChanges to system broadcasts\r\nAs the Android platform evolves, it periodically changes how system broadcasts behave. Keep the following\r\nchanges in mind to support all versions of Android.\r\nAndroid 16\r\nhttps://developer.android.com/guide/components/broadcasts#changes-system-broadcasts\r\nPage 1 of 13\n\nIn Android 16, broadcast delivery order using the android:priority attribute or IntentFilter.setPriority()\r\nacross different processes won't be guaranteed. Broadcast priorities are only respected within the same application\r\nprocess rather than across all processes.\r\nAlso, broadcast priorities are automatically confined to the range ( SYSTEM_LOW_PRIORITY + 1,\r\nSYSTEM_HIGH_PRIORITY - 1). Only system components are allowed to set SYSTEM_LOW_PRIORITY ,\r\nSYSTEM_HIGH_PRIORITY as broadcast priority.\r\nAndroid 14\r\nWhile apps are in a cached state, the system optimizes broadcast delivery for system health. For example, the\r\nsystem defers less important system broadcasts such as ACTION_SCREEN_ON while the app is in a cached state.\r\nOnce the app goes from the cached state into an active process lifecycle, the system delivers any deferred\r\nbroadcasts.\r\nImportant broadcasts that are declared in the manifest temporarily remove apps from the cached state for delivery.\r\nAndroid 9\r\nBeginning with Android 9 (API level 28), The NETWORK_STATE_CHANGED_ACTION broadcast doesn't receive\r\ninformation about the user's location or personally identifiable data.\r\nIf your app is installed on a device running Android 9.0 (API level 28) or higher, the system doesn't include\r\nSSIDs, BSSIDs, connection information, or scan results in Wi-Fi broadcasts. To get this information, call\r\ngetConnectionInfo() instead.\r\nAndroid 8.0\r\nBeginning with Android 8.0 (API level 26), the system imposes additional restrictions on manifest-declared\r\nreceivers.\r\nIf your app targets Android 8.0 or higher, you cannot use the manifest to declare a receiver for most implicit\r\nbroadcasts (broadcasts that don't target your app specifically). You can still use a context-registered receiver when\r\nthe user is actively using your app.\r\nAndroid 7.0\r\nAndroid 7.0 (API level 24) and higher don't send the following system broadcasts:\r\nACTION_NEW_PICTURE\r\nACTION_NEW_VIDEO\r\nAlso, apps targeting Android 7.0 and higher must register the CONNECTIVITY_ACTION broadcast using\r\nregisterReceiver(BroadcastReceiver, IntentFilter) . Declaring a receiver in the manifest doesn't work.\r\nReceive broadcasts\r\nhttps://developer.android.com/guide/components/broadcasts#changes-system-broadcasts\r\nPage 2 of 13\n\nApps can receive broadcasts in two ways: through context-registered receivers and manifest-declared receivers.\r\nContext-registered receivers\r\nContext-registered receivers receive broadcasts as long as their registering context is valid. This is typically\r\nbetween the calls to registerReceiver and unregisterReceiver . The registering context also becomes invalid\r\nwhen the system destroys the corresponding context. For example, if you register within an Activity context,\r\nyou receive broadcasts as long as the activity remains active. If you register with the Application context, you\r\nreceive broadcasts as long as the app runs.\r\nTo register a receiver with a context, perform the following steps:\r\n1. In your app's module-level build file, include version 1.9.0 or higher of the AndroidX Core library:\r\ndependencies {\r\n def core_version = \"1.18.0\"\r\n // Java language implementation\r\n implementation \"androidx.core:core:$core_version\"\r\n // Kotlin\r\n implementation \"androidx.core:core-ktx:$core_version\"\r\n // To use RoleManagerCompat\r\n implementation \"androidx.core:core-role:1.1.0\"\r\n // To use the Animator APIs\r\n implementation \"androidx.core:core-animation:1.0.0\"\r\n // To test the Animator APIs\r\n androidTestImplementation \"androidx.core:core-animation-testing:1.0.0\"\r\n // Optional - To enable APIs that query the performance characteristics of GMS devices.\r\n implementation \"androidx.core:core-performance:1.0.0\"\r\n // Optional - to use ShortcutManagerCompat to donate shortcuts to be used by Google\r\n implementation \"androidx.core:core-google-shortcuts:1.1.0\"\r\n // Optional - to support backwards compatibility of RemoteViews\r\n implementation \"androidx.core:core-remoteviews:1.1.0\"\r\n // Optional - APIs for SplashScreen, including compatibility helpers on devices prior Andr\r\n implementation \"androidx.core:core-splashscreen:1.2.0\"\r\n}\r\ndependencies {\r\n val core_version = \"1.18.0\"\r\nhttps://developer.android.com/guide/components/broadcasts#changes-system-broadcasts\r\nPage 3 of 13\n\n// Java language implementation\r\n implementation(\"androidx.core:core:$core_version\")\r\n // Kotlin\r\n implementation(\"androidx.core:core-ktx:$core_version\")\r\n // To use RoleManagerCompat\r\n implementation(\"androidx.core:core-role:1.1.0\")\r\n // To use the Animator APIs\r\n implementation(\"androidx.core:core-animation:1.0.0\")\r\n // To test the Animator APIs\r\n androidTestImplementation(\"androidx.core:core-animation-testing:1.0.0\")\r\n // Optional - To enable APIs that query the performance characteristics of GMS devices.\r\n implementation(\"androidx.core:core-performance:1.0.0\")\r\n // Optional - to use ShortcutManagerCompat to donate shortcuts to be used by Google\r\n implementation(\"androidx.core:core-google-shortcuts:1.1.0\")\r\n // Optional - to support backwards compatibility of RemoteViews\r\n implementation(\"androidx.core:core-remoteviews:1.1.0\")\r\n // Optional - APIs for SplashScreen, including compatibility helpers on devices prior Andr\r\n implementation(\"androidx.core:core-splashscreen:1.2.0\")\r\n}\r\n2. Create an instance of BroadcastReceiver :\r\nval myBroadcastReceiver = MyBroadcastReceiver()\r\nMyBroadcastReceiver myBroadcastReceiver = new MyBroadcastReceiver();\r\n3. Create an instance of IntentFilter :\r\nval filter = IntentFilter(\"com.example.snippets.ACTION_UPDATE_DATA\")\r\nIntentFilter filter = new IntentFilter(\"com.example.snippets.ACTION_UPDATE_DATA\");\r\nhttps://developer.android.com/guide/components/broadcasts#changes-system-broadcasts\r\nPage 4 of 13\n\n4. Choose whether the broadcast receiver should be exported and visible to other apps on the device. If this\r\nreceiver is listening for broadcasts sent from the system or from other apps—even other apps that you own\r\n—use the RECEIVER_EXPORTED flag. If instead this receiver is listening only for broadcasts sent by your\r\napp, use the RECEIVER_NOT_EXPORTED flag.\r\nval listenToBroadcastsFromOtherApps = false\r\nval receiverFlags = if (listenToBroadcastsFromOtherApps) {\r\n ContextCompat.RECEIVER_EXPORTED\r\n} else {\r\n ContextCompat.RECEIVER_NOT_EXPORTED\r\n}\r\nBroadcastReceiverSnippets.kt\r\nboolean listenToBroadcastsFromOtherApps = false;\r\nint receiverFlags = listenToBroadcastsFromOtherApps\r\n ? ContextCompat.RECEIVER_EXPORTED\r\n : ContextCompat.RECEIVER_NOT_EXPORTED;\r\nBroadcastReceiverJavaSnippets.java\r\n5. Register the receiver by calling registerReceiver() :\r\nContextCompat.registerReceiver(context, myBroadcastReceiver, filter, receiverFlags)\r\nContextCompat.registerReceiver(context, myBroadcastReceiver, filter, receiverFlags);\r\n6. To stop receiving broadcasts, call unregisterReceiver(android.content.BroadcastReceiver) . Be sure to\r\nunregister the receiver when you no longer need it or the context is no longer valid.\r\nUnregister your broadcast receiver\r\nWhile the broadcast receiver is registered, it holds a reference to the Context that you registered it with. This can\r\npotentially cause leaks if the receiver's registered scope exceeds the Context lifecycle scope. For example, this can\r\noccur when you register a receiver on an Activity scope, but you forget to unregister it when the system destroys\r\nthe Activity. Therefore, always unregister your broadcast receiver.\r\nhttps://developer.android.com/guide/components/broadcasts#changes-system-broadcasts\r\nPage 5 of 13\n\nclass MyActivity : ComponentActivity() {\r\n private val myBroadcastReceiver = MyBroadcastReceiver()\r\n override fun onCreate(savedInstanceState: Bundle?) {\r\n super.onCreate(savedInstanceState)\r\n // ...\r\n ContextCompat.registerReceiver(this, myBroadcastReceiver, filter, receiverFlags)\r\n setContent { MyApp() }\r\n }\r\n override fun onDestroy() {\r\n super.onDestroy()\r\n // When you forget to unregister your receiver here, you're causing a leak!\r\n this.unregisterReceiver(myBroadcastReceiver)\r\n }\r\n}\r\nBroadcastReceiverSnippets.kt\r\nclass MyActivity extends ComponentActivity {\r\n MyBroadcastReceiver myBroadcastReceiver;\r\n @Override\r\n protected void onCreate(Bundle savedInstanceState) {\r\n super.onCreate(savedInstanceState);\r\n // ...\r\n ContextCompat.registerReceiver(this, myBroadcastReceiver, filter, receiverFlags);\r\n // Set content\r\n }\r\n}\r\nBroadcastReceiverJavaSnippets.java\r\nRegister receivers in the smallest scope\r\nYour broadcast receiver should only be registered when you're actually interested in the result. Choose the\r\nsmallest possible receiver scope:\r\nLifecycleResumeEffect or activity onResume / onPause lifecycle methods: The broadcast receiver only\r\nreceives updates while the app is in its resumed state.\r\nhttps://developer.android.com/guide/components/broadcasts#changes-system-broadcasts\r\nPage 6 of 13\n\nLifecycleStartEffect or activity onStart / onStop lifecycle methods: The broadcast receiver only\r\nreceives updates while the app is in its resumed state.\r\nDisposableEffect : The broadcast receiver only receives updates while the composable is in the\r\ncomposition tree. This scope is not attached to the activity lifecycle scope. Consider registering the receiver\r\non the application context. This is because the composable could theoretically outlive the activity lifecycle\r\nscope and leak the activity.\r\nActivity onCreate / onDestroy : The broadcast receiver receives updates while the activity is in its\r\ncreated state. Make sure to unregister in onDestroy() and not onSaveInstanceState(Bundle) because\r\nthis might not be called.\r\nA custom scope: For example, you can register a receiver in your ViewModel scope, so it survives activity\r\nrecreation. Make sure to use the application context to register the receiver on, as the receiver can outlive\r\nthe activity lifecycle scope and leak the activity.\r\nCreate stateful and stateless composable\r\nCompose has stateful and stateless composables. Registering or unregistering a broadcast receiver inside a\r\ncomposable makes it stateful. The composable is not a deterministic function that renders the same content when\r\npassed the same parameters. Internal state can change based on calls to the registered broadcast receiver.\r\nAs a best practice in Compose, we recommend that you split your composables into stateful and stateless versions.\r\nTherefore, we recommend that you hoist the creation of the broadcast receiver out of a Composable to make it\r\nstateless:\r\n@Composable\r\nfun MyStatefulScreen() {\r\n val myBroadcastReceiver = remember { MyBroadcastReceiver() }\r\n val context = LocalContext.current\r\n LifecycleStartEffect(true) {\r\n // ...\r\n ContextCompat.registerReceiver(context, myBroadcastReceiver, filter, flags)\r\n onStopOrDispose { context.unregisterReceiver(myBroadcastReceiver) }\r\n }\r\n MyStatelessScreen()\r\n}\r\n@Composable\r\nfun MyStatelessScreen() {\r\n // Implement your screen\r\n}\r\nBroadcastReceiverSnippets.kt\r\nhttps://developer.android.com/guide/components/broadcasts#changes-system-broadcasts\r\nPage 7 of 13\n\nManifest-declared receivers\nIf you declare a broadcast receiver in your manifest, the system launches your app when the broadcast is sent. If\nthe app is not already running, the system launches the app.\nTo declare a broadcast receiver in the manifest, perform the following steps:\n1. Specify the element in your app's manifest.\nAndroidManifest.xml\nThe intent filters specify the broadcast actions your receiver subscribes to.\n2. Subclass BroadcastReceiver and implement onReceive(Context, Intent) . The broadcast receiver in\nthe following example logs and displays the contents of the broadcast:\nclass MyBroadcastReceiver : BroadcastReceiver() {\n @Inject\n lateinit var dataRepository: DataRepository\n override fun onReceive(context: Context, intent: Intent) {\n if (intent.action == \"com.example.snippets.ACTION_UPDATE_DATA\") {\n val data = intent.getStringExtra(\"com.example.snippets.DATA\") ?: \"No data\"\n // Do something with the data, for example send it to a data repository:\n dataRepository.updateData(data)\n }\n }\n}\nBroadcastReceiverSnippets.kt\nhttps://developer.android.com/guide/components/broadcasts#changes-system-broadcasts\nPage 8 of 13\n\npublic static class MyBroadcastReceiver extends BroadcastReceiver {\r\n @Inject\r\n DataRepository dataRepository;\r\n @Override\r\n public void onReceive(Context context, Intent intent) {\r\n if (Objects.equals(intent.getAction(), \"com.example.snippets.ACTION_UPDATE_DATA\")) {\r\n String data = intent.getStringExtra(\"com.example.snippets.DATA\");\r\n // Do something with the data, for example send it to a data repository:\r\n if (data != null) { dataRepository.updateData(data); }\r\n }\r\n }\r\n}\r\nBroadcastReceiverJavaSnippets.java\r\nThe system package manager registers the receiver when the app is installed. The receiver then becomes a\r\nseparate entry point into your app which means that the system can start the app and deliver the broadcast if the\r\napp is not running.\r\nThe system creates a new BroadcastReceiver component object to handle each broadcast that it receives. This\r\nobject is valid only for the duration of the call to onReceive(Context, Intent) . Once your code returns from\r\nthis method, the system considers the component no longer active.\r\nEffects on process state\r\nWhether your BroadcastReceiver is operating or not affects its contained process, which can alter its system-killing likelihood. A foreground process executes a receiver's onReceive() method. The system runs the process\r\nexcept under extreme memory pressure.\r\nThe system deactivates the BroadcastReceiver after onReceive() . The receiver's host process's significance\r\ndepends on its app components. If that process hosts only a manifest-declared receiver, the system might kill it\r\nafter onReceive() to free resources for other more critical processes. This is common for apps the user has never\r\nor not recently interacted with.\r\nThus, broadcast receivers shouldn't initiate long-running background threads. The system can stop the process at\r\nany moment after onReceive() to reclaim memory, terminating the created thread. To keep the process alive,\r\nschedule a JobService from the receiver using the JobScheduler so the system knows the process is still\r\nworking. Background Work Overview provides more details.\r\nSend broadcasts\r\nhttps://developer.android.com/guide/components/broadcasts#changes-system-broadcasts\r\nPage 9 of 13\n\nAndroid provides two ways for apps to send broadcasts:\r\nThe sendOrderedBroadcast(Intent, String) method sends broadcasts to one receiver at a time. As each\r\nreceiver executes in turn, it can propagate a result to the next receiver. It can also completely abort the\r\nbroadcast so that it doesn't reach other receivers. You can control the order in which receivers run within\r\nthe same app process. To do so, use the android:priority attribute of the matching intent-filter.\r\nReceivers with the same priority are run in an arbitrary order.\r\nThe sendBroadcast(Intent) method sends broadcasts to all receivers in an undefined order. This is called\r\na Normal Broadcast. This is more efficient, but means that receivers cannot read results from other\r\nreceivers, propagate data received from the broadcast, or abort the broadcast.\r\nThe following code snippet demonstrates how to send a broadcast by creating an Intent and calling\r\nsendBroadcast(Intent) .\r\nval intent = Intent(\"com.example.snippets.ACTION_UPDATE_DATA\").apply {\r\n putExtra(\"com.example.snippets.DATA\", newData)\r\n setPackage(\"com.example.snippets\")\r\n}\r\ncontext.sendBroadcast(intent)\r\nBroadcastReceiverSnippets.kt\r\nIntent intent = new Intent(\"com.example.snippets.ACTION_UPDATE_DATA\");\r\nintent.putExtra(\"com.example.snippets.DATA\", newData);\r\nintent.setPackage(\"com.example.snippets\");\r\ncontext.sendBroadcast(intent);\r\nBroadcastReceiverJavaSnippets.java\r\nThe broadcast message is wrapped in an Intent object. The intent's action string must provide the app's Java\r\npackage name syntax and uniquely identify the broadcast event. You can attach additional information to the\r\nintent with putExtra(String, Bundle) . You can also limit a broadcast to a set of apps in the same organization\r\nby calling setPackage(String) on the intent.\r\nRestrict broadcasts with permissions\r\nPermissions allow you to restrict broadcasts to the set of apps that hold certain permissions. You can enforce\r\nrestrictions on either the sender or receiver of a broadcast.\r\nSend broadcasts with permissions\r\nhttps://developer.android.com/guide/components/broadcasts#changes-system-broadcasts\r\nPage 10 of 13\n\nWhen you call sendBroadcast(Intent, String) or sendOrderedBroadcast(Intent, String,\nBroadcastReceiver, Handler, int, String, Bundle) , you can specify a permission parameter. Only receivers\nwho have requested that permission with the tag in their manifest can receive the broadcast.\nIf the permission is dangerous, you must grant the permission before the receiver can receive the broadcast. For\nexample, the following code sends a broadcast with a permission:\ncontext.sendBroadcast(intent, android.Manifest.permission.ACCESS_COARSE_LOCATION)\ncontext.sendBroadcast(intent, android.Manifest.permission.ACCESS_COARSE_LOCATION);\nTo receive the broadcast, the receiving app must request the permission as follows:\nYou can specify either an existing system permission like BLUETOOTH_CONNECT or define a custom permission\nwith the element. For information on permissions and security in general, see the System\nPermissions.\nReceive broadcasts with permissions\nIf you specify a permission parameter when registering a broadcast receiver (either with\nregisterReceiver(BroadcastReceiver, IntentFilter, String, Handler) or in tag in your\nmanifest), then only broadcasters who have requested the permission with the tag in their\nmanifest can send an Intent to the receiver. If the permission is dangerous, the broadcaster must also be granted\nthe permission.\nFor example, assume your receiving app has a manifest-declared receiver as follows:\nAndroidManifest.xml\nhttps://developer.android.com/guide/components/broadcasts#changes-system-broadcasts\nPage 11 of 13\n\nOr your receiving app has a context-registered receiver as follows:\nContextCompat.registerReceiver(\n context, myBroadcastReceiver, filter,\n android.Manifest.permission.ACCESS_COARSE_LOCATION,\n null, // scheduler that defines thread, null means run on main thread\n receiverFlags\n)\nBroadcastReceiverSnippets.kt\nContextCompat.registerReceiver(\n context, myBroadcastReceiver, filter,\n android.Manifest.permission.ACCESS_COARSE_LOCATION,\n null, // scheduler that defines thread, null means run on main thread\n receiverFlags\n);\nBroadcastReceiverJavaSnippets.java\nThen, to be able to send broadcasts to those receivers, the sending app must request the permission as follows:\nSecurity considerations\nHere are some security considerations for sending and receiving broadcasts:\nIf many apps have registered to receive the same broadcast in their manifest, it can cause the system to\nlaunch a lot of apps, causing a substantial impact on both device performance and user experience. To\navoid this, prefer using context registration over manifest declaration. Sometimes, the Android system\nitself enforces the use of context-registered receivers. For example, the CONNECTIVITY_ACTION broadcast is\ndelivered only to context-registered receivers.\nDon't broadcast sensitive information using an implicit intent. Any app can read the information if it\nregisters to receive the broadcast. There are three ways to control who can receive your broadcasts:\nhttps://developer.android.com/guide/components/broadcasts#changes-system-broadcasts\nPage 12 of 13\n\nYou can specify a permission when sending a broadcast.\r\nIn Android 4.0 (API level 14) and higher, you can specify a package with setPackage(String)\r\nwhen sending a broadcast. The system restricts the broadcast to the set of apps that match the\r\npackage.\r\nWhen you register a receiver, any app can send potentially malicious broadcasts to your app's receiver.\r\nThere are several ways to limit the broadcasts that your app receives:\r\nYou can specify a permission when registering a broadcast receiver.\r\nFor manifest-declared receivers, you can set the android:exported attribute to \"false\" in the\r\nmanifest. The receiver does not receive broadcasts from sources outside of the app.\r\nThe namespace for broadcast actions is global. Make sure that action names and other strings are written in\r\na namespace you own. Otherwise, you may inadvertently conflict with other apps.\r\nBecause a receiver's onReceive(Context, Intent) method runs on the main thread, it should execute and\r\nreturn quickly. If you need to perform long-running work, be careful about spawning threads or starting\r\nbackground services because the system can kill the entire process after onReceive() returns. For more\r\ninformation, see Effect on process state To perform long running work, we recommend:\r\nCalling goAsync() in your receiver's onReceive() method and passing the\r\nBroadcastReceiver.PendingResult to a background thread. This keeps the broadcast active after\r\nreturning from onReceive() . However, even with this approach the system expects you to finish\r\nwith the broadcast very quickly (under 10 seconds). It does allow you to move work to another\r\nthread to avoid glitching the main thread.\r\nScheduling a job with the JobScheduler . For more information, see Intelligent Job Scheduling.\r\nDon't start activities from broadcast receivers because the user experience is jarring; especially if there is\r\nmore than one receiver. Instead, consider displaying a notification.\r\nSource: https://developer.android.com/guide/components/broadcasts#changes-system-broadcasts\r\nhttps://developer.android.com/guide/components/broadcasts#changes-system-broadcasts\r\nPage 13 of 13",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://developer.android.com/guide/components/broadcasts#changes-system-broadcasts"
	],
	"report_names": [
		"broadcasts#changes-system-broadcasts"
	],
	"threat_actors": [],
	"ts_created_at": 1775434869,
	"ts_updated_at": 1775791283,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/1618bcd261cf90013dec2557f4da02b24cabd7de.pdf",
		"text": "https://archive.orkl.eu/1618bcd261cf90013dec2557f4da02b24cabd7de.txt",
		"img": "https://archive.orkl.eu/1618bcd261cf90013dec2557f4da02b24cabd7de.jpg"
	}
}