MediaWiki API result

{
    "batchcomplete": "",
    "continue": {
        "gapcontinue": "SQLite",
        "continue": "gapcontinue||"
    },
    "warnings": {
        "main": {
            "*": "Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/postorius/lists/mediawiki-api-announce.lists.wikimedia.org/> for notice of API deprecations and breaking changes."
        },
        "revisions": {
            "*": "Because \"rvslots\" was not specified, a legacy format has been used for the output. This format is deprecated, and in the future the new format will always be used."
        }
    },
    "query": {
        "pages": {
            "3727": {
                "pageid": 3727,
                "ns": 0,
                "title": "Recovery",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "[[File:Android_recovery_y200.jpg|thumbnail|The stock recovery of a Huawei device]]\n[[File:ClockWorkMod_y200.jpg|thumbnail|ClockWorkMod on a Huawei device]]\n\nA '''recovery'''-system, also known as just ''the recovery'', is the name of a system in android devices to recover from possible system start failures. The system can also be seen as a minimum operating system on Android devices, which can be used to fulfill several tasks, as the creation of backups of single partitions or the installation of a new ROM. Basically, the community differentiates between officially distributed recovery systems from the vendors (such as Samsung or HTC) and community/alternative recovery systems (also known as ''custom recovery''). Most commonly known ones of the latter group are [[ClockWorkMod]] and the [[TeamWin Recovery Project]].\n\n== Functions ==\nA recovery systems main use case is to ''recover'' the system from major software-based failures and defects, e.g. if the Android operating system does not start correctly anymore. The recovery system is saved on a specific partition of the [[Internal Storage|internal storage]] of the device.\n\nApart from recovering the device by flashing a new copy of the operating system of the device, it can also be used to install completely new operating systems or updates to the existing one. It's not unusual, that update packages are installed using the recovery system, after they were downloaded as part of the so called [[OTA|OTA update process]].\n\n== Stock recovery ==\nThe device vendors install a customized version of a minimal recovery system on the device. It usually has a very limited scope of functionality and it's main intention is to do automated update installations or to wipe specific partitions of the device.\n\nTo overcome this minimalistic function scope, users may be able to install custom recoveries.\n\n== Custom recovery ==\nCommunity developers are also providing alternative recovery systems, called custom recoveries. These systems usually provide a much broader set of functionality, even though some of them are based on the stock recovery. They can be used to freely wipe data from any partition of the device (which can lead in an even more broken system as before, when done by an unexperienced user), or install images on them. The most common alternative recoveries are the [[TeamWin Recovery Project|TWRP]] (TeamWin Recovery Project) and the [[ClockWorkMod]] recovery.\n\nUnlike most of the stock recoveries, the most recent versions of custom recoveries often support input of the user using the touchscreen, instead of the mechanical volume and power keys.\n\n== Flash or boot (test) a recovery ==\nA new recovery system (or the stock recovery back to the device) usually can be flashed using [[fastboot]]. The ''flash'' command is used in a form such as (windows):<syntaxhighlight lang=\"powershell\">\nfastboot flash recovery C:\\Pfad\\zum\\Recovery.img\n</syntaxhighlight>Additionally, in more recent versions of fastboot, the recovery system can also be started once on the device, only. This can be especially useful, if the currently installed recovery is not intended to be replaced or the new system should only be tested if it provides all necessary functionality.\n\nIt is also useful in order to create a backup of the currently installed recovery system, if it does not provide functionality to do so on its own.\n\nTo temporarily start a recovery system, the fastboot command ''boot'' can be used:<syntaxhighlight lang=\"powershell\">\nfastboot boot C:\\Pfad\\zum\\Recovery.img\n</syntaxhighlight>As the recovery system is not being installed on the device, a simple restart brings back the currently installed recovery of the system.\n\n== See also ==\n\n* [[TeamWin Recovery Project]]"
                    }
                ]
            },
            "3573": {
                "pageid": 3573,
                "ns": 0,
                "title": "Root",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "'''Root''', also named '''Root-Account''' or '''Root'''-Account-'''Access''', in [[Wikipedia:en:Unix-like|unix-like]] systems, including Android, means, that a user has full access to the operating system and the resources of it.\n\nThe synonym term ''Root'' is derived from the linux user ''root'', which, in the users- and rights hierarchy of linux, is the top element and therefore has wide system permissions. Root-user are also called ''Superuser''.\n\nIn Android, the root-access is deactivated by default. Using the root-user for working with the system is, for security reasons, not provided.\n\n== Root in Unix-like systems ==\nThe user account ''root'' is, in a unix-like system like BSD or linux, created by default during the installation of the system. This user is not meant to be used during the daily work with the system, as a potential security risk arises from the wide system permissions assigned to this user. Because of this risk, the ''root'' user is usually only used to do administrative tasks in the system, which requires extended permissions compared to other user accounts.\n\n=== Switching the identity ===\nIn Ubunut, a linux distribution, a switch of the identity (the user account) is possible at any time, as long as the current user has the permission to do so. Actions, that require root-permissions, are, e.g., the installation of a new program or the change of a configuration of an already installed one. However, also malicious software, to do malicious tasks, often requires root permission. In the default configuration, if a program requires root-permission, the user is asked to confirm this request by entering their password. This is not required, if the user is working as the root-account already.\n\nTo avoid unauthorized access, confirming this request or entering the root password, should only be done, if the user actively started a program that requires root access. The requirement of root-access should also be evaluated before granting the access (e.g. a mail program usually do not need root access to do it's work).\n\nIn a terminal ([[shell]]), switching to the root account is done with the command <code>su</code> ('''s'''ubstitute '''u'''ser identity). Executing this command (and confirming this with the root password) will open an interactive shell, the so-called ''root-shell''. All commands executed in this shell also have the root permission as well. If only one command should be executed with root-permissions, the command should be executed by prepending the <code>sudo</code> command, which will only execute this single command in a root-context.\n\n== Root in Android ==\nAs there is no real user account management in Android {{Android|5.0}}, like in a personal computer, the user does not really have a identity, which they could change. The user is, more precisely, switching from app to app, which gets the required permission during the installation of them (since Android {{Android|6.0}}, the user can grant the permission of an app once the app really needs it). The user impersonates the identity of each single app while using it. For each [[app]], the [[Dalvik VM]] is assigning it a unique user ID (UID)<ref>{{Cite web|url=http://www.zdnet.de/41553061/android-architektur-wieviel-linux-steckt-in-googles-os/|title=Android-Architektur: Wieviel Linux steckt in Googles OS?|date=2011-05-18|website=ZDNet.de|language=de-DE|access-date=2020-02-02}}</ref>, which, by default, has only read and write permissions to the data directory of this specific app (located in the /data/data directory).\n\n=== Permission-management in Android ===\n[[File:Superuser.png|thumb|Root request by an app on a HTC Wildfire]]\nAs Android is based on the linux kernel, it also inherits most of the security features of it, e.g. the permission management. To be able to install an app, e.g. from the [[Google Play Store]], the user must grant this app the required permissions to work (e.g. access to the internet or telephone functions). Each app is only able to access features of the system, which the user granted during the installation (or update). The developer of the app states the required permissions in the meta-file '''AndroidManifest.xml''' of their app. From this file, the Android system gets the required permissions for the app, which the user needs to confirm.\n\nGiven, that a malicious app wants to send or receive SMS, the developer of that app would need to request the required permission to send and receive SMS in the ''AndroidManifest.xml'' file when shipping this malicious app, in order to be able to access this telephone functions. In theory, this concept does not allow an app to gather permissions that were not granted by the user during the install time of the app. It is therefore an important step to check the required permissions of an app before installing it and also checking, that the requested app really requires all of these permissions to do it's job. For example, a calendar app usually does not have a good reason to request the permission to make or receive phone calls, however, accessing the events storage is reasonable.\n\nSince Android {{Android|4.3}} a new feature called [[App Ops]] allows a user to decline specific permissions of an app. Before it was only possible to grant all or no permissions (by not installing the app at all).\n\n=== Root for Android ===\nThe ''AndroidManifest.xml'' file does not provide the possibility to request permissions assigned to the ''root'' user. Permissions of the root user in Android are, as in other unix-like systems, realized with the File-permission ''setuid''.<ref>{{Cite web|url=http://www.androidnext.de/news/android-4-3-der-tod-der-root-rechte/|title=Android 4.3: Der Tod der Root-Rechte?|date=2013-07-29|website=GIGA|language=de|access-date=2020-02-02}}</ref> This bit controls, if a executable file is executed with the permissions of the executing user (e.g. the user created during the installation of the app) or with the permissions of the creator (for system commands usually ''root''). If an app requires ''root''-permissions, this usually simply means, that the app wants to execute another program (usually a system command) with root-permissions. Usually this is done by the app by running the desired command or executable file with the <code>su</code> binary (in the ''/system/xbin'' directory). This ''su'' binary is the only executable file, which is allowed to use the <code>setuid()</code> command ti change the setuid bit. To still give the full control of what app requested root-access and which one was granted, there's an app to administrate these requests and grants. One of these apps is [https://supersuroot.org/ SuperSU]. If the user starts an app that requires root-permission, the administrative app intercepts this request and asks the user for permission to (usually) either grant temporary or permanent root access to the app.\n\nHowever, the user should always verify the request of root permission by an app by comparing the expected features of an app with the requirement to execute commands which require root permission. Most daily work apps out for Android usually do not require root permission, the permission system of Android provides them all the necessary permissions.\n\n== Refrences ==\n<references />"
                    }
                ]
            }
        }
    }
}