{
	"id": "88df479e-e1e2-4006-b6e8-3d2832734f11",
	"created_at": "2026-04-06T01:30:15.940438Z",
	"updated_at": "2026-04-10T03:28:03.003625Z",
	"deleted_at": null,
	"sha1_hash": "5de2279ed88a3f80a861e5da0d1925b817a5f4ff",
	"title": "Behavior changes: all apps",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 152529,
	"plain_text": "Behavior changes: all apps\r\nArchived: 2026-04-06 00:59:31 UTC\r\nAndroid 9 (API level 28) introduces a number of changes to the Android system. The following behavior changes\r\napply to all apps when they run on the Android 9 platform, regardless of the API level that they are targeting. All\r\ndevelopers should review these changes and modify their apps to support them properly, where applicable to the\r\napp.\r\nFor changes that only affect apps that target API level 28 or higher, see Behavior changes: apps targeting API\r\nLevel 28+.\r\nPower management\r\nAndroid 9 introduces new features to improve device power management. These changes, along with features that\r\nwere already present before Android 9, help to ensure that system resources are made available to the apps that\r\nneed them the most.\r\nFor details, see Power management.\r\nPrivacy changes\r\nTo enhance user privacy, Android 9 introduces several behavior changes, such as limiting background apps' access\r\nto device sensors, restricting information retrieved from Wi-Fi scans, and new permission rules and permission\r\ngroups related to phone calls, phone state, and Wi-Fi scans.\r\nThese changes affect all apps running on Android 9, regardless of target SDK version.\r\nLimited access to sensors in background\r\nAndroid 9 limits the ability for background apps to access user input and sensor data. If your app is running in the\r\nbackground on a device running Android 9, the system applies the following restrictions to your app:\r\nYour app cannot access the microphone or camera.\r\nSensors that use the continuous reporting mode, such as accelerometers and gyroscopes, don't receive\r\nevents.\r\nSensors that use the on-change or one-shot reporting modes don't receive events.\r\nIf your app needs to detect sensor events on devices running Android 9, use a foreground service.\r\nRestricted access to call logs\r\nAndroid 9 introduces the CALL_LOG permission group and moves the READ_CALL_LOG , WRITE_CALL_LOG , and\r\nPROCESS_OUTGOING_CALLS permissions into this group. In previous versions of Android, these permissions were\r\nhttps://developer.android.com/about/versions/pie/android-9.0-changes-all#bg-sensor-access\r\nPage 1 of 10\n\nlocated in the PHONE permission group.\r\nThis CALL_LOG permission group gives users better control and visibility to apps that need access to sensitive\r\ninformation about phone calls, such as reading phone call records and identifying phone numbers.\r\nIf your app requires access to call logs or needs to process outgoing calls, you must explicitly request these\r\npermissions from the CALL_LOG permission group. Otherwise, a SecurityException occurs.\r\nNote: Because these permissions have changed groups and are granted at runtime, it's possible for the user to deny\r\nyour app access to phone call logs information. In this case, your app should be able to handle the lack of access\r\nto information gracefully.\r\nIf your app is already following runtime permissions best practices, it can handle the change in permission group.\r\nRestricted access to phone numbers\r\nApps running on Android 9 cannot read phone numbers or phone state without first acquiring the READ_CALL_LOG\r\npermission, in addition to the other permissions that your app's use cases require.\r\nPhone numbers associated with incoming and outgoing calls are visible in the phone state broadcast, such as for\r\nincoming and outgoing calls and are accessible from the PhoneStateListener class. Without the\r\nREAD_CALL_LOG permission, however, the phone number field that's provided in PHONE_STATE_CHANGED\r\nbroadcasts and through PhoneStateListener is empty.\r\nTo read phone numbers from phone state, update your app to request the necessary permissions based on your use\r\ncase:\r\nTo read numbers from the PHONE_STATE intent action, you need both the READ_CALL_LOG permission and\r\nthe READ_PHONE_STATE permission.\r\nTo read numbers from onCallStateChanged() , you need the READ_CALL_LOG permission only. You don't\r\nneed the READ_PHONE_STATE permission.\r\nRestricted access to Wi-Fi location and connection information\r\nIn Android 9, the permission requirements for an app to perform Wi-Fi scans are more strict than in previous\r\nversions. For details, see Wi-Fi scanning restrictions.\r\nSimilar restrictions also apply to the getConnectionInfo() method, which returns a WifiInfo object describing\r\nthe current Wi-Fi connection. You can only use this object's methods to retrieve SSID and BSSID values if the\r\ncalling app has the following permissions:\r\nACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION\r\nACCESS_WIFI_STATE\r\nRetrieving the SSID or BSSID also requires location services to be enabled on the device (under Settings \u003e\r\nLocation).\r\nhttps://developer.android.com/about/versions/pie/android-9.0-changes-all#bg-sensor-access\r\nPage 2 of 10\n\nInformation removed from Wi-Fi service methods\r\nIn Android 9, the following events and broadcasts don't receive information about the user's location or personally\r\nidentifiable data:\r\nThe getScanResults() and getConnectionInfo() methods from WifiManager .\r\nThe discoverServices() and addServiceRequest() methods from WifiP2pManager .\r\nThe NETWORK_STATE_CHANGED_ACTION broadcast.\r\nThe NETWORK_STATE_CHANGED_ACTION system broadcast from Wi-Fi no longer contains SSID (previously\r\nEXTRA_SSID), BSSID (previously EXTRA_BSSID), or connection information (previously\r\nEXTRA_NETWORK_INFO). If your app needs this information, call getConnectionInfo() instead.\r\nTelephony information now relies on device location setting\r\nIf the user has disabled device location on a device running Android 9, the following methods don't provide\r\nresults:\r\ngetAllCellInfo()\r\nlisten()\r\ngetCellLocation()\r\ngetNeighboringCellInfo()\r\nRestrictions on use of non-SDK interfaces\r\nTo help ensure app stability and compatibility, the platform restricts the use of some non-SDK methods and fields;\r\nthese restrictions apply whether you attempt to access these methods and fields directly, via reflection, or using\r\nJNI. In Android 9, your app can continue to access these restricted interfaces; the platform uses toasts and log\r\nentries to bring them to your attention. If your app shows such a toast, it is important that you pursue an\r\nimplementation strategy other than the restricted interface. If you feel that no alternative strategy is feasible, you\r\nmay file a bug to request reconsideration of the restriction.\r\nRestrictions on Non-SDK Interfaces contains further important information. You should review it to ensure that\r\nyour app continues to function properly.\r\nSecurity behavior changes\r\nDevice security changes\r\nAndroid 9 adds several capabilities that improve your app's security, regardless of which version your app targets.\r\nTLS implementation changes\r\nThe system's TLS implementation has undergone several changes in Android 9:\r\nhttps://developer.android.com/about/versions/pie/android-9.0-changes-all#bg-sensor-access\r\nPage 3 of 10\n\nIf an instance of SSLSocket fails to connect while it's being created, the system throws an IOException\r\ninstead of a NullPointerException .\r\nThe SSLEngine class cleanly handles any close_notify alerts that occur.\r\nTo learn more about making secure web requests in an Android app, see An HTTPS example.\r\nStricter SECCOMP filter\r\nAndroid 9 further restricts the system calls that are available to apps. This behavior is an extension of the\r\nSECCOMP filter that Android 8.0 (API level 26) includes.\r\nCryptographic changes\r\nAndroid 9 introduces several changes to the implementation and handling of cryptographic algorithms.\r\nConscrypt implementations of parameters and algorithms\r\nAndroid 9 provides additional implementations of algorithm parameters in Conscrypt. These parameters include:\r\nAES, DESEDE, OAEP, and EC. The Bouncy Castle versions of these parameters and many algorithms have been\r\ndeprecated as of Android 9.\r\nIf your app targets Android 8.1 (API level 27) or lower, you receive a warning when requesting the Bouncy Castle\r\nimplementation of one of these deprecated algorithms. If you target Android 9, however, these requests each throw\r\na NoSuchAlgorithmException .\r\nOther changes\r\nAndroid 9 introduces several other changes related to cryptography:\r\nWhen using PBE keys, if Bouncy Castle is expecting an initialization vector (IV) and your app doesn’t\r\nsupply one, you receive a warning.\r\nThe Conscrypt implementation of the ARC4 cipher allows you to specify either ARC4/ECB/NoPadding\r\nor ARC4/NONE/NoPadding.\r\nThe Crypto Java Cryptography Architecture (JCA) provider has been removed. As a result, if your app\r\ncalls SecureRandom.getInstance(\"SHA1PRNG\", \"Crypto\") , a NoSuchProviderException occurs.\r\nIf your app parses RSA keys from buffers that are larger than the key structure, an exception no longer\r\noccurs.\r\nTo learn more about using Android's cryptographic capabilities, see Cryptography.\r\nAndroid secure encrypted files are no longer supported\r\nAndroid 9 completely removes support for Android secure encrypted files (ASECs).\r\nIn Android 2.2 (API level 8), Android introduced ASECs to support apps-on-SD-card functionality. On Android\r\n6.0 (API level 23), the platform introduced an adoptable storage device technology that developers can use in\r\nhttps://developer.android.com/about/versions/pie/android-9.0-changes-all#bg-sensor-access\r\nPage 4 of 10\n\nplace of ASECs.\r\nUpdates to the ICU libraries\r\nAndroid 9 uses version 60 of the ICU library. Android 8.0 (API level 26) and Android 8.1 (API level 27) use ICU\r\n58.\r\nICU is used to provide public APIs beneath the android.icu package and is used internally in the Android\r\nplatform for internationalization support. For example, it is used to implement Android classes in java.util ,\r\njava.text , and android.text.format .\r\nThe update to ICU 60 contains many small but useful changes, including Emoji 5.0 data support and improved\r\ndate/time formats, as documented in the ICU 59 and ICU 60 release notes.\r\nNotable changes in this update:\r\nThe way the platform handles time zones has changed.\r\nThe platform handles GMT and UTC better; UTC is no longer a synonym for GMT.\r\nICU now provides translated zone names for GMT and UTC. This change affects android.icu\r\nformatting and parsing behavior for zones like \"GMT\", \"Etc/GMT\", \"UTC\", \"Etc/UTC\", and\r\n\"Zulu\".\r\njava.text.SimpleDateFormat now uses ICU to provide display names for UTC /GMT, meaning:\r\nFormatting zzzz generates a long localized string for many locales. Previously, it produced\r\n\"UTC\" for UTC and strings like \"GMT+00:00\" for GMT.\r\nParsing zzzz recognizes strings like \"Universal Coordinated Time\", and \"Greenwich Mean\r\nTime\".\r\nApps may encounter compatibility problems if they assume that \"UTC\" or \"GMT+00:00\" are\r\noutput for zzzz in all languages.\r\nThe behavior of java.text.DateFormatSymbols.getZoneStrings() has changed:\r\nAs with SimpleDateFormat , UTC and GMT now have long names. DST variants of time\r\nzone names for the UTC zone, such as \"UTC\", \"Etc/UTC\", and \"Zulu\", become\r\nGMT+00:00, which is the standard fallback when there are no names available, rather than\r\nthe hard-coded string UTC .\r\nSome zone IDs are correctly recognized as synonyms for other zones, so that Android finds\r\nstrings for archaic zone IDs, such as Eire , that previously could not be resolved.\r\nAsia/Hanoi is no longer a recognized zone. For this reason\r\njava.util.TimeZones.getAvailableIds() does not return this value, and\r\njava.util.TimeZone.getTimeZone() does not recognize it. This behavior is consistent with the\r\nexisting android.icu behavior.\r\nThe android.icu.text.NumberFormat.getInstance(ULocale, PLURALCURRENCYSTYLE).parse(String)\r\nmethod may throw a ParseException even when parsing legitimate currency text. Avoid this problem by\r\nusing NumberFormat.parseCurrency , available since Android 7.0 (API level 24), for\r\nPLURALCURRENCYSTYLE -style currency text.\r\nhttps://developer.android.com/about/versions/pie/android-9.0-changes-all#bg-sensor-access\r\nPage 5 of 10\n\nAndroid Test changes\r\nAndroid 9 introduces several changes to the Android Test framework's library and class structure. These changes\r\nhelp developers use framework-supported, public APIs, but the changes also allow for more flexibility in building\r\nand running tests using third-party libraries or custom logic.\r\nLibraries removed from framework\r\nAndroid 9 reorganizes the JUnit-based classes into three libraries: android.test.base, android.test.runner, and\r\nandroid.test.mock. This change allows you to run tests against a version of JUnit that works best with your\r\nproject's dependencies. This version of JUnit might be different than the one that android.jar provides.\r\nTo learn more about how the JUnit-based classes are organized into these libraries, as well as how to prepare your\r\napp's project for writing and running tests, see Set up project for Android Test.\r\nTest suite build changes\r\nThe addRequirements() method in the TestSuiteBuilder class has been removed, and the TestSuiteBuilder\r\nclass itself been deprecated. The addRequirements() method had required developers to supply arguments\r\nwhose types are hidden APIs, making the API invalid.\r\nJava UTF decoder\r\nUTF-8 is the default charset in Android. A UTF-8 byte sequence can be decoded by a String constructor, such\r\nas String(byte[] bytes) .\r\nThe UTF-8 decoder in Android 9 follows the Unicode standards more strictly than in previous versions. The\r\nchanges include the following:\r\nThe non-shortest form of UTF-8, such as \u003cC0, AF\u003e , is treated as ill-formed.\r\nThe surrogate form of UTF-8, such as U+D800 .. U+DFFF , is treated as ill-formed.\r\nThe maximal subpart is replaced by a single U+FFFD . For example, in the byte sequence \" 41 C0 AF 41 F4\r\n80 80 41 ,\" the maximal subparts are \" C0 ,\" \" AF ,\" and \" F4 80 80 .\" \" F4 80 80 \" can be the initial\r\nsubsequence of \" F4 80 80 80 \", but \" C0 \" can't be the initial subsequence of any well-formed code unit\r\nsequence. Thus, the output should be \" A\\ufffd\\ufffdA\\ufffdA .\"\r\nTo decode a modified UTF-8 / CESU-8 sequence in Android 9 or higher, use the\r\nDataInputStream.readUTF() method or the NewStringUTF() JNI method.\r\nHostname verification using a certificate\r\nRFC 2818 describes two methods to match a domain name against a certificate—using the available names within\r\nthe subjectAltName ( SAN ) extension, or in the absence of a SAN extension, falling back to the commonName\r\n( CN ).\r\nhttps://developer.android.com/about/versions/pie/android-9.0-changes-all#bg-sensor-access\r\nPage 6 of 10\n\nHowever, the fallback to the CN was deprecated in RFC 2818. For this reason, Android no longer falls back to\r\nusing the CN . To verify a hostname, the server must present a certificate with a matching SAN . Certificates that\r\ndon't contain a SAN matching the hostname are no longer trusted.\r\nNetwork address lookups can cause network violations\r\nNetwork address lookups that require name resolution can involve network I/O and are therefore considered\r\nblocking operations. Blocking operations on the main thread can cause pauses or jank.\r\nThe StrictMode class is a development tool that helps developers to detect problems in their code.\r\nIn Android 9 and higher, StrictMode detects network violations caused by network address lookups that require\r\nname resolution.\r\nYou should not ship your apps with StrictMode enabled. If you do, then your apps can experience exceptions,\r\nsuch as NetworkOnMainThreadException when using the detectNetwork() or detectAll() methods to get a\r\npolicy that detects network violations.\r\nResolving a numeric IP address isn't considered a blocking operation. Numeric IP address resolution works the\r\nsame as in versions before Android 9.\r\nSocket tagging\r\nIn platform versions lower than Android 9, if a socket is tagged using the setThreadStatsTag() method, the\r\nsocket is untagged when it's sent to another process using binder IPC with a ParcelFileDescriptor container.\r\nIn Android 9 and higher, the socket tag is kept when it’s sent to another process using binder IPC. This change can\r\naffect network traffic statistics, for example, when using the queryDetailsForUidTag() method.\r\nIf you want to retain the behavior of the previous versions, which untags a socket that is sent to another process,\r\nyou can call untagSocket() before sending the socket.\r\nReported amount of available bytes in socket\r\nThe available() method returns 0 when it's called after invoking the shutdownInput() method.\r\nMore detailed network capabilities reporting for VPNs\r\nIn Android 8.1 (API level 27) and lower, the NetworkCapabilities class only reported a limited set of\r\ninformation for VPNs, such as TRANSPORT_VPN , but omitting NET_CAPABILITY_NOT_VPN . This limited information\r\nmade it difficult to determine if using a VPN would result in charges to the app's user. For example, checking\r\nNET_CAPABILITY_NOT_METERED would not determine whether the underlying networks were metered or not.\r\nIn Android 9 and higher, when a VPN calls the setUnderlyingNetworks() method, the Android system merges\r\nthe transports and capabilities of any underlying networks and returns the result as the effective network\r\ncapabilities of the VPN network.\r\nhttps://developer.android.com/about/versions/pie/android-9.0-changes-all#bg-sensor-access\r\nPage 7 of 10\n\nIn Android 9 and higher, apps that already check for NET_CAPABILITY_NOT_METERED receive the network\r\ncapabilities of the VPN and the underlying networks.\r\nFiles in xt_qtaguid folder are no longer available to apps\r\nBeginning with Android 9, apps are not allowed to have direct read access to files in the /proc/net/xt_qtaguid\r\nfolder. The reason is to ensure consistency with some devices that don't have these files at all.\r\nThe public APIs that rely on these files, TrafficStats and NetworkStatsManager , continue to work as\r\nintended. However, the unsupported cutils functions, such as qtaguid_tagSocket() , may not work as expected—\r\nor at all— on different devices.\r\nFLAG_ACTIVITY_NEW_TASK requirement is now enforced\r\nWith Android 9, you cannot start an activity from a non-activity context unless you pass the intent flag\r\nFLAG_ACTIVITY_NEW_TASK . If you attempt to start an activity without passing this flag, the activity does not start,\r\nand the system prints a message to the log.\r\nScreen rotation changes\r\nBeginning with Android 9, there are significant changes to the portrait rotation mode. In Android 8.0 (API level\r\n26), users could toggle between auto-rotate and portrait rotation modes using a Quicksettings tile or Display\r\nsettings. The portrait mode has been renamed rotation lock and it is active when auto-rotate is toggled off. There\r\nare no changes to auto-rotate mode.\r\nWhen the device is in rotation lock mode, users can lock their screen to any rotation supported by the top, visible\r\nActivity. An Activity should not assume it will always be rendered in portrait. If the top Activity can be rendered\r\nin multiple rotations in auto-rotate mode, the same options should be available in rotation locked mode, with some\r\nexceptions based on the Activity's screenOrientation setting (see the table below).\r\nActivities that request a specific orientation (for example, screenOrientation=landscape ) ignore the user lock\r\npreference and behave the same way as in Android 8.0.\r\nThe screen orientation preference can be set at the Activity level in the Android Manifest, or programmatically\r\nwith setRequestedOrientation().\r\nThe rotation lock mode works by setting the user rotation preference which the WindowManager uses when\r\nhandling Activity rotation. The user rotation preference might be changed in the following cases. Note that there is\r\na bias to return to the device's natural rotation, which is normally portrait for phone form factor devices:\r\nWhen the user accepts a rotation suggestion the rotation preference changes to the suggestion.\r\nWhen the user switches to a forced portrait app (including the lock screen or the launcher) the rotation\r\npreference changes to portrait.\r\nThe following table summarizes rotation behavior for the common screen orientations:\r\nhttps://developer.android.com/about/versions/pie/android-9.0-changes-all#bg-sensor-access\r\nPage 8 of 10\n\nScreen Orientation Behavior\r\nunspecified, user\r\nIn auto-rotate and rotation lock the Activity can be rendered in portrait or\r\nlandscape (and the reverse). Expect to support both portrait and landscape\r\nlayouts.\r\nuserLandscape\r\nIn auto-rotate and rotation lock the Activity can be rendered in either\r\nlandscape or reverse landscape. Expect to support only landscape layouts.\r\nuserPortrait\r\nIn auto-rotate and rotation lock the Activity can be rendered in either\r\nportrait or reverse portrait. Expect to support only portrait layouts.\r\nfullUser\r\nIn auto-rotate and rotation lock the Activity can be rendered in portrait or\r\nlandscape (and the reverse). Expect to support both portrait and landscape\r\nlayouts.\r\nRotation lock users will be given the option to lock to reverse portrait, often\r\n180º.\r\nsensor, fullSensor,\r\nsensorPortrait,\r\nsensorLandscape\r\nThe rotation lock mode preference is ignored and is treated as if auto-rotate\r\nis active. Only use this in exceptional circumstances with very careful UX\r\nconsideration.\r\nApache HTTP client deprecation affects apps with non-standard ClassLoader\r\nWith Android 6.0, we removed support for the Apache HTTP client. This change has no effect on the great\r\nmajority of apps that do not target Android 9 or higher. However, the change can affect certain apps that use a\r\nnonstandard ClassLoader structure, even if the apps do not target Android 9 or higher.\r\nAn app can be affected if it uses a non-standard ClassLoader that explicitly delegates to the system\r\nClassLoader . These apps need to delegate to the app ClassLoader instead when looking for classes in\r\norg.apache.http.* . If they delegate to the system ClassLoader , the apps will fail on Android 9 or higher with\r\na NoClassDefFoundError , because those classes are no longer known to the system ClassLoader . To prevent\r\nsimilar problems in the future, apps should in general load classes through the app ClassLoader rather than\r\naccessing the system ClassLoader directly.\r\nEnumerating cameras\r\nApps running on Android 9 devices can discover every available camera by calling getCameraIdList() . An app\r\nshould not assume that the device has only a single back camera or only a single front camera.\r\nFor example, if your app has a button to switch between the front and back cameras, there may be more than one\r\nfront or back camera to choose from. You should walk the camera list, examine each camera's characteristics, and\r\ndecide which cameras to expose to the user.\r\nhttps://developer.android.com/about/versions/pie/android-9.0-changes-all#bg-sensor-access\r\nPage 9 of 10\n\nSource: https://developer.android.com/about/versions/pie/android-9.0-changes-all#bg-sensor-access\r\nhttps://developer.android.com/about/versions/pie/android-9.0-changes-all#bg-sensor-access\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://developer.android.com/about/versions/pie/android-9.0-changes-all#bg-sensor-access"
	],
	"report_names": [
		"android-9.0-changes-all#bg-sensor-access"
	],
	"threat_actors": [
		{
			"id": "1a76ed30-4daf-4817-98ae-87c667364464",
			"created_at": "2022-10-25T16:47:55.891029Z",
			"updated_at": "2026-04-10T02:00:03.646466Z",
			"deleted_at": null,
			"main_name": "IRON LIBERTY",
			"aliases": [
				"ALLANITE ",
				"ATK6 ",
				"BROMINE ",
				"CASTLE ",
				"Crouching Yeti ",
				"DYMALLOY ",
				"Dragonfly ",
				"Energetic Bear / Berserk Bear ",
				"Ghost Blizzard ",
				"TEMP.Isotope ",
				"TG-4192 "
			],
			"source_name": "Secureworks:IRON LIBERTY",
			"tools": [
				"ClientX",
				"Ddex Loader",
				"Havex",
				"Karagany",
				"Loek",
				"MCMD",
				"Sysmain",
				"xfrost"
			],
			"source_id": "Secureworks",
			"reports": null
		}
	],
	"ts_created_at": 1775439015,
	"ts_updated_at": 1775791683,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/5de2279ed88a3f80a861e5da0d1925b817a5f4ff.pdf",
		"text": "https://archive.orkl.eu/5de2279ed88a3f80a861e5da0d1925b817a5f4ff.txt",
		"img": "https://archive.orkl.eu/5de2279ed88a3f80a861e5da0d1925b817a5f4ff.jpg"
	}
}