181 pagesV  < 1 2 3 4 5 6 > »  
 
REPLY
> Linux kernel from the inside | all questions about Linux kernel
coolkaas
Message#1
20.11.14, 20:40
viewer
*********
[offline]

Group: Friendssavagemessiahzine.com
Messages 5969
Check in: 09.11.10
Xiaomi Redmi 4X 3/32

Reputation:-  849  +

All answers to android nuclear questions: how the Linux kernel is organized in general and for Android in particular, the interaction mechanisms inside the kernel, kernel programming, discussion of various errors that occur during kernel assembly and operation, general kernel configuration rules and other system issues.
It discusses the kernel at the source level. Because of this, it is recommended to attach a link to the repository with the kernel sources, protocols (dmesg) in text form to your question.
It is better to set questions for assembling kernel images and packaging these images into a specific loader format for a specific device in a specialized topic.section. For example,Self-compiled kernel from source, Android 4.4.x (KitKat) / 5.x.x (Lollipop) / 6.x.x (Marshmallow) / 7.x.x (Nougat) kernel build for MTK processors, Assistance in the development and porting of Android OS on MTK devices, Developing Android 6.0 kernel and firmware for Asus Zenfone Go, Development and porting for devices on the Spreadtrum SC7731 platform, Development of kernels and firmware Redmi 4 (prada), RockChip rk3188 and newer, kernel build and moreetc.
The topic has grown from here:Shell scripts for Android. The parent theme discusses the system issues of the functioning of Android in the user space (userspace): the initial start, low-level interaction with the system components of the Android.

Linux kernel regulatory materials
  • The founding document on the Android device internals, Android Interfaces and Architecture, contains a sectionKernelwhich outlines the basic requirements for the core from the Android side, highlights the issues of configuring the kernel, optimizing individual components of the kernel, etc.
Some materials of the topic:

For questions of filling and updating the topic header, the Curator is always ready to help you.username11

Post has been editedusername11 - 26.07.18, 15:29
Reason for editing: Added section with regulatory materials
Timofey777
Message#42
11.12.14, 22:23
FiveGFox
********
[offline]

Group: Curators
Messages 1656
Check in: 24.06.12
Huawei P10 Lite WAS-LX1

Reputation:-  280  +

* Ruslancun
Only source, only hardcore!


--------------------
Huawei P10 Lite Android 8
vitaly51370
Message#43
11.12.14, 23:45
Libero
*********
[offline]

Group: Friendssavagemessiahzine.com
Messages 3475
Check in: 16.11.12
LG G3 S

Reputation:-  1638  +

* username11,when the current CPU load is enabled (in the "For Developers" settings), the lines kworker / 0: 1, kworker / 1: 2 skip on the screen, if you perform any actions with the tablet, a line may appear, for example kworker / u: 1 highlighted for a second in green. As far as I know, kworker is a kernel process associated with interrupts. What do the numbers / letters after the slash mean and what is this one-time green light?


--------------------
LG G3s D724

Visitor7
Message#44
12.12.14, 01:09
Old resident
*******
[offline]

Group: Friendssavagemessiahzine.com
Messages 1008
Check in: 17.03.13

Reputation:-  187  +

username11,1. If these 5 drivers were all the time dry, I could calculate the imputed value as loadavg minus 5. But they sometimes work, and, from my point of view, unpredictable. While I sit in the terminal, their activity can be neglected.
2. As far as I understand, RAD is the desire to make a low-functional, but quite ready-to-use product and develop it along the way. “Aby what”, “aby like” and “in haste” are not mandatory conditions.
username11
Message#45
12.12.14, 13:29
User
*********
[offline]

Topics Curator
Group: Curators
Messages 11477
Check in: 04.07.11
HTC Desire S

Reputation:-  2190  +

* Ruslancun, * sera19966, something many with such devices suddenly had very specific questions. Give full details. To make it clear your Wishlist.
* vitaly51370, not necessarily with interrupts, kworker - the process processing workqueue, the format of its name is described in Documentation / kernel-per-CPU-kthreads.txt, workqueue - in Documentation / workqueue.txt, in Linux Device Drivers. u - unbound worqueue.
* Visitor7, yes, here you have made a "low-functional, but quite ready-to-use product" - put wait_event / msleep instead of the _interruptible option. "A cho, less type the same." And now you break your head.
dushkin_alex
Message#46
13.12.14, 18:45
really
*******
[offline]

Group: Friendssavagemessiahzine.com
Messages 901
Check in: 04.01.12
Apple iPhone 5s

Reputation:-  103  +

Attention, the question ... :) Where do you get the kernel sources from? Or - how to parse already compiled?

Post has been editeddushkin_alex - 13.12.14, 18:49


--------------------
BlackBerry Club
Rip. Mix. Burn
iPhone 5s @ 32GB.
Azathtot
Message#47
13.12.14, 19:18
Magos biologis
*********
[offline]

Group: Developers
Messages 11909
Check in: 05.05.13
Huawei MediaPad 7 Vogue S7-601u, S7-602u

Reputation:-  1051  +

* dushkin_alex
disassemble - no way, dig with kernel.org


--------------------
Order. Unity. Obedience.
dushkin_alex
Message#48
13.12.14, 19:28
really
*******
[offline]

Group: Friendssavagemessiahzine.com
Messages 901
Check in: 04.01.12
Apple iPhone 5s

Reputation:-  103  +

Sorry for the nouveau, but what should I download from there?


--------------------
BlackBerry Club
Rip. Mix. Burn
iPhone 5s @ 32GB.
Azathtot
Message#49
13.12.14, 19:32
Magos biologis
*********
[offline]

Group: Developers
Messages 11909
Check in: 05.05.13
Huawei MediaPad 7 Vogue S7-601u, S7-602u

Reputation:-  1051  +

* dushkin_alex
The one you need. Depends on your android version. And then you need somewhere to get patches from the manufacturer of the body and apply them. Taking the "vanilla" kernel makes sense only for x86 systems and for studying "how it works."


--------------------
Order. Unity. Obedience.
dushkin_alex
Message#50
13.12.14, 19:46
really
*******
[offline]

Group: Friendssavagemessiahzine.com
Messages 901
Check in: 04.01.12
Apple iPhone 5s

Reputation:-  103  +

OMFG ... but can the manufacturer provide them or not?


--------------------
BlackBerry Club
Rip. Mix. Burn
iPhone 5s @ 32GB.
Azathtot
Message#51
13.12.14, 19:52
Magos biologis
*********
[offline]

Group: Developers
Messages 11909
Check in: 05.05.13
Huawei MediaPad 7 Vogue S7-601u, S7-602u

Reputation:-  1051  +

* dushkin_alex
Can. But it will not.


--------------------
Order. Unity. Obedience.
adm_
Message#52
14.12.14, 01:30
#define false rand ()% 2
*********
[offline]

Group: Friendssavagemessiahzine.com
Messages 3105
Check in: 10.12.08
Zopo ZP980 +

Reputation:-  261  +

Where to dig up the sources of the kernel?

if you are very lucky, then m. Something is built on the github (github), you need to look for your piece of iron and all its synonyms / copies, then check the author's nickname, do his kernels work / lay out, and only then download and try to build ...


--------------------
When asking a question, it is necessary to know the percent answer at 70. Otherwise, it is meaningless to ask it: nothing will be clear from the answer anyway.
dushkin_alex
Message#53
14.12.14, 01:34
really
*******
[offline]

Group: Friendssavagemessiahzine.com
Messages 901
Check in: 04.01.12
Apple iPhone 5s

Reputation:-  103  +

Well, I have a piece of iron Snapdragon 200 + Adreno 203 ... I do not know the rest of the info.


--------------------
BlackBerry Club
Rip. Mix. Burn
iPhone 5s @ 32GB.
adm_
Message#54
14.12.14, 18:15
#define false rand ()% 2
*********
[offline]

Group: Friendssavagemessiahzine.com
Messages 3105
Check in: 10.12.08
Zopo ZP980 +

Reputation:-  261  +

I have a piece of iron

misunderstood: in the context of a piece of iron = rattle = Prestigio MultiPhone 5400 DUO (as I understand it).

I do not know the rest of the info.

you have no idea how much you have to learn about your piece of iron and about the different subtleties of kernel assembly, before you assemble the first one that works more or less ... ;-)

I repeat: if you don’t find the source that is deliberately collected for your piece of iron (or for a copy / synonym, if you have one), then it’s best not to take it at all ...
it is still quite funny to scare away: only the assembly team (which lasts from 40 minutes to 1.5 hours and which from the first to the tenth time is unlikely to give the desired result) of the kernel is 2 lines of a full-screen terminal, and you will ask again / google almost all of its keys and parameters. ..; -Ъ

* Ruslancun, * Sera19966, Something with such devices suddenly suddenly had very specific questions. Give full details. To make it clear your Wishlist.

but what is there to understand - on devdb it is written: "Random access memory (MB): 512", "Operating system: Android 4.1" ;-) a cheap dvuhsimochnik with a small memory and a sickly processor, on which, most likely (I guess), have piled up 4.4 . * ... ;-)
... on 512mb, it is necessary even to 4.0.4 to tune and tune, so as not to slow down, although without Zetram you still cannot achieve smooth operation of the navigation ...

Post has been editedadm_ - 14.12.14, 20:23


--------------------
When asking a question, it is necessary to know the percent answer at 70. Otherwise, it is meaningless to ask it: nothing will be clear from the answer anyway.
username11
Message#55
14.12.14, 19:29
User
*********
[offline]

Topics Curator
Group: Curators
Messages 11477
Check in: 04.07.11
HTC Desire S

Reputation:-  2190  +

The mechanisms of functioning of the root-rights on Android or many books 2
The mechanisms of functioning of the root-rights on Android or many books 2

Part 1. Android to version 4.3
Or rather, not even “up to version 4.3,” and even not Linux, we will begin, perhaps, from the times of immemorial, when “the sun was shining brighter, the girls were younger”, and the concepts were simpler.
The user with the number (uid) 0 in the Unix family of operating systems traditionally had a number of privileges that allow, for example, to ignore file permissions, mount disk devices, configure network interfaces, send any signal to any process, etc. In other words, this user is usually called root, could perform any action in the operating system, regardless of the limitations in it, i.e., in essence, was an administrator. Android uses the Linux kernel, therefore, is one of the versions of the Unix family of operating systems, and, in this sense, the root user (with uid 0) in Android has the same administrative privileges as the rest of the operating systems of this family - he is allowed everything.
Another thing is that in the standard Android there is no possibility to perform the operation on behalf of the user with uid 0. Google simply does not put the necessary utilities into the firmware. This “restriction” is easy to manage: add the su utility to the firmware, set the suid bit on the utility executable file, and assign the user with uid 0 to the owner of the file. The suid bit instructs the OS kernel to execute the utility on behalf of the user owning the executable file. (and not on behalf of the user who launched it). And since the owner of the file is root, we get a process that has all the privileges. Actually, this mechanism is a standard way of obtaining administrative privileges in the Unix world and existed long before Android.
Those who want more details or who do not understand anything yet. Totally.
In the Unix family of operating systems, the traditional system of privilege separation is based, in particular, on the notion of a user identifier (uid) - a non-negative integer. Each process has an owner (uid) and an image — an executable file containing a program (code, data). Each file, including the executable, also has an owner. When a process is created (and the only way to create a new process is to execute the fork system call in an existing process), the owner and image of the new process are inherited from the parent process. When replacing an image with another executable file (via exec system calls), the owner usually does not change. However, if the executable file has a suid bit, then the process owner (per owner of the executable file) also changes with the image.

It seems to be nothing complicated, but in Android the mechanism of changing the owner of the process is surrounded by a sort of mystery veil, which is to blame for several reasons. First and foremost, most Android users, if they have heard about Unix and Linux, are only in the news.(However, the vast majority of them do not understand how administrative rights work on other operating systems.)Secondly, Android has its own system of differentiation of rights (which any user encountered when installing applications from the Google Play store), and to denote access on behalf of a user with uid 0, the most common term is “root-rights”. As a result, it is not surprising that the majority consider “root-rights” one of the rights of Android, such as the right to send SMS. And this, of course, is not. Android permissions are granted by Android itself, user rights with uid 0 - the Linux kernel. The difference is subtle, but essential to understand further. The “consistency” of Android and user rights with uid 0 also contributes to this misconception - when, for example, we send SMS, Android performs the following check: does the application performing this operation have the right to send SMS or (!) Whether the process is performed on behalf of with uid 0. Why Google needed this is not known for certain. Conspiracy therapists believe that this was part of Google’s cunning plan to conquer the world. The advocates of the “corporation of good” are confident that Google’s engineers specifically provided such opportunities for lovers of digging into the firmware. The invention of some android.permission.ACCESS_SUPERUSER also contributes additional confusion. Why it was needed at all, these modders themselves are not able to give a clear answer, of course. But as a result, we have a supposedly Android right somehow connected with the root-rights, which greatly increases confusion in thoughts. (However, there are enough real problems too.) Google, naturally, ignores this right, since it was not determined by Android itself, however, when installing applications, it regularly reports about it. Rather, he reported before the release of Android 5.0, in which Google severely limited the game to far-fetched rights, effectively placing a ban on the use of rights other than those invented by himself.(And despite the cries of conspiracy theorists, it was not done because of the right android.permission.ACCESS_SUPERUSER, it was required to hit the playful hands on completely different players of the Android application market.)
Now let's discuss in more detail the previously mentioned “subtle but significant” difference. An application that has the right to send SMS can do this by simply calling the Android function. However, in order to perform an operation that requires root-rights, it is necessary, having created a separate process, to run the su utility in it. There are no means to get additional rights for an existing process in the OS of the Unix family, it is simply never necessary, moreover, it is harmful. (That is why in the paragraph above, “application” and “process” were mentioned separately, although I hope that it is clear that the application is always executed as part of some process.) The inability to add rights to the process, in particular, means the following. When the application “file manager” copies files to the sd card, it simply calls the corresponding Android procedures inside it. However, when he needs to copy files to / system, the application will have to: 1) create a new process; 2) run the su utility in this new process, which will lead to a change in the process owner; 3) the utility, having executed authorization (about it a bit later), will replace itself with the command shell - the shell; 4) the file manager will launch in the shell the file copy utility, cp. As we see, immediately after point 1) Android remains out of work, all operations are performed, bypassing it. This, by the way, causes problems if you need to perform a privileged operation within the framework of Android itself. Fortunately, the need for such delights is small - Google provided Android with a bunch of various utilities, ostensibly for debugging, allowing you to do almost everything except for very exotic things.
At this point, it is the promised “later”, let's talk about authorization of “root-rights”, i.e., about control over their issuance to applications. In the Unix world, everything is simple - we run su, it asks for the root password, we enter it, su replaces itself with a shell. In Android, users do not have any passwords, and su is obviously not bothering with the password input to the su utility. Therefore, a special application is attached to the utility - the root-rights requester, called Superuser, CWM Superuser, SuperSU, thousands of them already. The main task of this interrogator is the authorization of root-rights for a particular application in a person. Additionally, any requestor logs operations performed on behalf of the root user. Usually, everything is considered to be turned upside down: the requester is supposedly the main application, and the su utility is an appendage to it. You can probably imagine everything that way, but we will not do that. If only because the requestor application can, like any other application, be installed from the Google Play store, but you will not receive any special privileges from such an action.(By the way, it’s not necessary to make the requestor a system application, that is, to place it in the / system / app directory, where the “cargo cult” went from, let future historians understand.)Since the methods for exchanging authorization information are unique for each requestor, implementations of the su utilities for which the requesters are intended are incompatible with each other. In other words, su for the Superuser application will not work with CWM Superuser or SuperSU applications and vice versa.
Finishing the conversation about root-rights for Android earlier versions, I will describe a detailed algorithm for obtaining root-rights by applications:
1. The application spawns a new process (the fork system call), in which it executes the su utility (the exec system call). Standard input, standard output, and standard error output (stdin, stout, and stderr) are assigned to pipes (pipes) connecting the child process (su) to the parent process (application).
2. Since the su file is set to suid, and the owner is root, the kernel, when exec the system call, assigns the new owner, the root user, to this process.
3. The su utility authorizes the operation through a special root-rights requester application (or, in some cases, performing the necessary checks itself, however, such details are not very important). The requestor asks for permission to issue rights to the person and returns the answer to the su utility.
4. If authorization is unsuccessful, su notifies the root-rights requester about it and quits.
5. If the authorization is successful, su replaces its image with the executable file with the shell utility (again via the exec system call), informing the interrogator about it.
6. Now the application requesting root-rights has a child process with a shell (running as the root user), which can issue commands to the stdin channel, receiving responses from stdout and stderr.
Note: The su utility can run not only the shell and not only with the root owner. She has all sorts of interesting options, leaving them to the reader to study for independent study.
Part 2. Android version 4.3 and above
Starting from 4.3, Google radically changed the rules of the game, replacing the traditional Unix privilege system (“all available root”) with the “capabilities” system. This, in turn, led to dramatic changes in the way su worked.
When using the “powers” ​​system, each administrative action is limited by its own powers. For example, the CAP_FOWNER authority allows you to ignore file access rights, the CAP_SYS_ADMIN authority allows you to mount disk devices, CAP_NET_ADMIN — configure network interfaces, CAP_KILL — ignore restrictions on sending signals to processes. This approach allows you to avoid the concentration of all privileges in one user-administrator (virus, trojan). In the Linux kernel, the system of powers was also used long before the appearance of the Android. Another thing is that in Linux distributions the system of authority is practically not used - the root user is given all the permissions, the rest ... well, you understand. Therefore, although the core inside itself is hardworking to check the powers, it is not visible from the outside: still, there is root and there is“Trembling creatures”all other users.
Google, however, made the user with uid 0 the most ordinary user, depriving all processes of authority. A small loophole, as you understand, is still there (you can get root on all Androids). The fact is that some processes with uid 0 still have the full set of permissions. Say, the very first process, init, with the number (pid) 1, started by the kernel itself, has the root user (who else) and all the permissions, the processes started personally by the init process, inherit a set of permissions from it. But all applications in Android are started by another process (it is called zygote), which, although it is a descendant of init, however, immediately after launch, resets all powers, depriving those and all their descendant processes. And not just dumping, but also instructing the core so that it does not give its descendant processes (and their descendants) any new powers. Thus, starting with Android 4.3, it is no longer able to obtain any application privileges. And for greater reliability, Google also instructed the Linux kernel to ignore suid bits on executable files in the / system section. To do this, a code was added directly to the Dalvik virtual machine, remounting the / system partition with the nosuid option for the zygote process (and, therefore, all its descendants).
Shooting off the suid bit for processes spawned by zygote uses another unusual Linux kernel mechanism — the mount namespace namespace. Google first applied it back in Android 4.2 to support the multiplayer mode in Android. However, the mount point namespaces worked in 4.2, even when there was exactly one user on the system.
I note that the “user” in Android, although it is also identified by a nonnegative integer, does not at all coincide with the concept of the uid of the core. The uid system in Android from the very beginning was used to identify applications, and when Google had to invent the user identification system, the engineers found an elegant solution that amazes with its immediacy - the Android user ID is stored ... in the upper digits of the uid.
Let's go back to the namespaces, perhaps. In traditional operating systems of the Unix family (and in other operating systems familiar to us), all names were global, accessible to all (taking into account privileges, of course), i.e., if two processes used the same name, they were guaranteed to refer to the same same object. However, in Linux, you can create a process with its own separate namespace (usually, you still need to have certain rights), and the same names in different namespaces do not necessarily refer to the same object. There are several types of namespaces (and Android uses some of them), but to understand the mechanisms of the functioning of the "root-rights" we are primarily interested in the namespaces of the mount points. So, in Android 4.2, such space was created for each application separately, so when an application mounted a new file system (created a new mount point) or remounted an existing one, it was only visible to this application and no one else (strictly speaking, also processes that are in the same namespace, but this is unimportant). For example, a user remounted / system for read-write in a file manager application, but when entering the terminal emulator application, he detected ... correctly, / system, still mounted only for reading.(What at first puzzled not so much the hamsters as many specialists. The first in such cases stupidly studied the place where, as it seemed to them just recently, their hands grow. The latter, of course, included the head, but most of them didn’t believe at first that the developer "Neskushny oboin" for smartphones and tablets will screw up on the system like this.)
In Android 4.3, as I said above, the zygote process began to additionally remount the / system partition with the nosuid option in its own space, so the application namespaces (as descendants of the zygote process namespace) inherit / system with this option.
We could not even talk about all these capabilities and namespaces, limiting ourselves to the statement “the root user does not have privileges in Android 4.3 and higher”, having supported what was said with the expressions “boy’s word”, “I give a tooth” and “infa 100%”, however firstly, it’s not in my rules, but, secondly ... And, secondly, besides the zygote process and applications, there is the adbd daemon responsible for the operation of the Android Debug Bridge (ADB). It is created by the init process (and not by zygote), and the concentration camp was staged to it to a slightly lesser extent. The processes generated by the adbd daemon (and these are ADB sessions) also live in their own namespace (one for all), but / system is mounted without the nosuid option, in addition, Google generously left the CAP_SETUID authority to such processes, i.e., you can change the owner process on the user with uid 0. Just do something meaningful on behalf of such a user will not work - neither CAP_FOWNER, nor CAP_SYS_ADMIN, nor CAP_KILL Google and did not issue such processes - the demon shoots himself these powers immediately after the start. However, the id command regularly reports the current uid 0. This is exactly what the phrase “Google made root as a regular user” means (However, since, unlike zygote, there is no prohibition on obtaining new privileges in the adb session, then .)
So, what we have in the end. We have the initial mount point namespace for the init process and its descendants, all processes except adbd (and its descendants) and zygote (and its descendants) are owned by the root user and have a full set of permissions. Applications (i.e., the descendants of zygote) cannot change the owner for their descendants. Applications have no authority and cannot be added in principle. In adb sessions, the owner can be changed, but the user with uid 0 initially will not have any useful privileges, this can be changed by explicitly setting the necessary permissions (for example, setting them for the su executable file, like the suid bit). By the way, to those who believe that this is bad, I will object that it is still good. Now malware (viruses and trojans) on a non-hardened Android is much harder to do something really harmful.
Having full-fledged init, the root-rights functions will have to be performed on behalf of the process - a descendant of init. Therefore, the su utility for Android 4.3 and above is “cut” into two parts: the su daemon, launched by init (or its descendant, which is insignificant), and the su utility itself, which is a bridge (proxy) between the application (or adb session) and the daemon. How to run the demon su - a separate conversation and uninteresting to us, the ways with all the details are easily found in other sources. Let's talk better about changes in the algorithm for issuing root-rights to applications.
1. The application spawns a new process in which it executes the su utility. Standard input, standard output, and standard error output streams are assigned to the channels connecting the child process (su) to the parent process (application). [This item, of course, does not change.]
2. “Since the su executable is set to suid ...” This item completely disappears for applications. But for adb sessions, too, of course, the owner of the process can be changed to uid 0, but I’m confused about that.
2 '. Therefore, the su utility communicates with the su daemon, passing it its stdin, stout, and stderr streams received from the application or adb session. (In Linux, such tricks are possible.) The flow transfer mechanisms for the application and for the session are slightly different, but this is irrelevant to us.
3, 4 Somewhere in this place (where it depends on the implementation of the utility) the action is authorized. Whether this makes the utility itself or the demon is not so important for us. Of course, a special application is still used for authorization - the root-rights requester. In the same way, a demon or utility (or even both, independently of each other), when receiving a response, inform the interrogator about the results.
5. The daemon spawns the process in which the shell executes, and binds the threads passed to it as stdin, stdout, and stderr to this process. Thus, the channels created in the application, passing through the utility and daemon, are attached to the process with a shell, uid 0 and all the permissions.
6. Now the application requesting root-rights [as before] can issue shell commands to the stdin channel, receiving responses from stdout and stderr.
7. The su utility waits from the daemon return code from the shell process to return this code to the application. [Previously, the return code was delivered to the application by itself, since the root-shell was a direct descendant of the process with the application.]
As we see, nothing has changed in principle - the application still has access to the process with uid 0 and all permissions. The devil, however, is in the details. Since now the process with the root-shell is not a direct descendant of the application (it is generated by the su daemon), some mechanisms of interaction between the parent process and the descendant process are not available. For example, by requesting the parent process number from a root shell, an application is surprised to find that it does not match the process number in which it runs itself. This, however, is nothing more than annoying little things. Worse, the mount point namespaces are different! Therefore, transferring to the root-shell, for example, the command to create a file in a directory on an sd-card, the application receives in response a “directory does not exist” error. What really surprises not so much the application as the user. But even if the su daemon duplicated all the mount points from the application's name space (their utility su knows and can share this knowledge with the daemon), i.e. in fact, the names in the application and root-shell namespaces are the same; these spaces themselves are different. For example, having mounted a disk device in the root-shell, the application detects that, from its point of view, there are no files or directories on the device, which it happily reports to a very perplexed user.
It is clear that such a sudden behavior of the root-rights causes hamsters to scream that the files on the device are inaccessible, as well as answers from other experts that Google allegedly denied users access to the sd card. Due to a not so random coincidence, Google did slightly change the rules for accessing the sd card in Android 4.3, but this is a separate topic of discussion. We have a typical two-way combination (changing the rules of access to the card, a change in the behavior of the root-rights), which can no longer be solved by an ordinary person. As a rule, the most intelligent ones guess only about one aspect of the problem, for example, they download and launch some kind of “card fixer”, however, the inability of the human brain to solve problems of two actions for psychologists has long been an axiom.
Finishing the story about the root of rights in Android 4.3 and above, I also note that in addition to capabilities and namespaces, Google also used the SELinux subsystem (project SEAndroid) in Android, and more and more new restrictions were added to 4.3, 4.4 and 5.0. As a result, for example, even with the “full-fledged” root-access provided by the su daemon, you cannot edit the system file you like, because it is protected from changes already at the SELinux level. In fact, you can, of course, but you need to know what the SELinux context is and how to set it for the process. I think, however, that within this narrative, the story of SELinux will be superfluous.

Thank you forumchaninPicture vodoleyvlfor the labor of proofreading this text and forumchaninPicture adm_for spelling editing.

Post has been editedusername11 - 05.02.15, 20:49
adm_
Message#56
14.12.14, 20:06
#define false rand ()% 2
*********
[offline]

Group: Friendssavagemessiahzine.com
Messages 3105
Check in: 10.12.08
Zopo ZP980 +

Reputation:-  261  +

* username11,
just spelling editing:
izoretennyh ->invented.

... from my point of view, it is required:
1) the final description of working (and now common) workarounds for androids 4.3 and above;
2) "many books 2" suggests the presence of "many books 1", which has no link and which is missing in this topic (but curiously)

fan elot, in the sense of 2x moments in the text did not know / remember. ;-)

Post has been editedadm_ - 14.12.14, 20:13


--------------------
When asking a question, it is necessary to know the percent answer at 70. Otherwise, it is meaningless to ask it: nothing will be clear from the answer anyway.
Visitor7
Message#57
15.12.14, 13:03
Old resident
*******
[offline]

Group: Friendssavagemessiahzine.com
Messages 1008
Check in: 17.03.13

Reputation:-  187  +

It is clear why the Chinese are so long stuck on 4.2.2))) For rutting 4.3 and above, is it necessary to edit ramdisk? I can’t imagine where else daemonsu can be run with full rights except init.rc or init.d (same init.rc). But at the same time, patches-rutovalschiki like and can do without it, or am I missing something?

Post has been editedVisitor7 - 15.12.14, 13:05
username11
Message#58
15.12.14, 14:30
User
*********
[offline]

Topics Curator
Group: Curators
Messages 11477
Check in: 04.07.11
HTC Desire S

Reputation:-  2190  +

* adm_thank you corrected. 1) "Bypass ways" for what? Ruth on 4.3+ is. 2) And search? : D
* Visitor7, 1. no, not therefore, most likely. Read the CDD for 4.2 and 4.3, there, for sure, there are significant differences like OpenGL ES 3.0, memory size, etc. 2. Ramdisk picking is not necessary, you learned how to start your own from your own in the parent theme. Do you think others do not know about it? There are, for example, install-recovery.sh.
Visitor7
Message#59
15.12.14, 18:07
Old resident
*******
[offline]

Group: Friendssavagemessiahzine.com
Messages 1008
Check in: 17.03.13

Reputation:-  187  +

username11,I saw patches pushing the daemon to install-recovery.sh, but I didn’t think that this is the main method. It certainly worked on my two Chinese, but in general ... What is the probability that the official firmware of an unknown phone launches this script from rc?
username11
Message#60
16.12.14, 15:06
User
*********
[offline]

Topics Curator
Group: Curators
Messages 11477
Check in: 04.07.11
HTC Desire S

Reputation:-  2190  +

* Visitor7, apparently, even if the Chinese work, then - 99%. For the remaining exotic use other places. In fact, as long as init will run the binaries from / system / bin, without dropping privileges, running the su daemon will not pose any special problems.
acdev
Message#61
19.12.14, 00:47
Developer
*********
[offline]

Group: Friendssavagemessiahzine.com
Messages 2272
Check in: 20.01.12
Highscreen Boost 2 SE

Reputation:-  644  +

Mirror works touch, in the kernel (the driver is not from him), can I get this driver out of the standard boot, and insert it into the right one?

If you have msm platform and synaptics tach driver, then you can simply specify in devtree that the tach should be mirrored along one of their axes (synaptics, x-flip and synaptics, y-flip parameters).

Timofey777 @ 11.12.2014, 22:23*
* Ruslancun
Only source, only hardcore!

No need to gossip.

It seems that the topic is devoted to the internals of the kernel, and administration and general architecture are discussed. Go to linux.org and have a discussion there.


--------------------
1) Siemens S45i ->Siemens E71 ->Motorola DROID Mini
2) HighScreen Boost 2 SE rev.A CM11
Development of a custom kernel for HighScreen Boost 2 SE

181 pagesV  < 1 2 3 4 5 6 > » 


 mobile version    Now: 05/20/19 07:45