Custom ROM survey - Android Q&A, Help & Troubleshooting

Hi everyone,
We are conducting a survey on the current usage of custom ROMs and user interests and I'd like as many users as possible to answer the very few questions: https://bit.ly/2gM1Ntv (survey is closed now)
Why all this?
We believe that the current custom ROM world and choice is not very nice. We basically have a single large player and a few smaller ones providing official builds and then there are many "homemade" ROMs of doubtful trust. Newbies that care about privacy and free software are scared of homemade ROMs, don't like CM and usually have a device not officially supported by the smaller ROMs. We are thus discussing if we should start a whole new ROM (maybe robbing some hardware code from CM) or contribute to an existing one. Our focus is on security and privacy and some of our ideas might be hard to achieve inside the currently existing ROMs.
We don't want to re-invent the wheel if it's not necessary, a ROM that nobody wants to use is just a waste of time.
To know if our ideas of a custom ROM are supported by the community, we need to know what you think about custom ROMs and our ideas on it.
If you want to discuss this further or want to give your opinion on this publicly, fill this thread up with whatever you want. We don't bite.
Thank you for your time,
Marvin

Personally I would like a ROM based on CyanogenMod (since I like 90% of the ROM) with:
- microG included
- Integrated XPrivacy (but rewritten inside the ROM without Xposed)
- Ability to hide root to specific apps on-the-fly without restart (with the code included inside the ROM impossible to detect)
- Ability to simulate other phones to specific apps on-the-fly without restart
- ARMv7 to ARMv6 software emulation for apps that support only ARMv7 on ARMv6 phones (probably slow but better than anything, ARMv7 to x86 emulation already exist)

ale5000 said:
Personally I would like a ROM based on CyanogenMod (since I like 90% of the ROM) with:
Click to expand...
Click to collapse
Problem with CM base is that it is partly proprietary (contains some google libraries). Read about freecyngn for details.
ale5000 said:
microG included
Click to expand...
Click to collapse
Plan is a sort of "setup wizard" that allows to install microG and of course the required patches as part of the ROM.
ale5000 said:
Integrated XPrivacy (but rewritten inside the ROM without Xposed)
Click to expand...
Click to collapse
Three-state deny/spoof/allow is already on our wishlist as well as extending the permission model to be more fine-grained.
ale5000 said:
Ability to hide root to specific apps on-the-fly without restart (with the code included inside the ROM impossible to detect)
Click to expand...
Click to collapse
The idea is to have a root system that works the opposite to what some su hiding tools do: the su binary is only available to certain apps the user preselected. This will also hide it to apps that should not see it. This way we can't have a nice "grant root permissions" dialog, but these are insecure nonetheless.
ale5000 said:
Ability to simulate other phones to specific apps on-the-fly without restart
Click to expand...
Click to collapse
What exactly do you want to simulate. The device name as returned by Build.MODEL? Note that it is technically impossible to simulate a whole other device in a way that can't be recognized
ale5000 said:
ARMv7 to ARMv6 software emulation for apps that support only ARMv7 on ARMv6 phones (probably slow but better than anything, ARMv7 to x86 emulation already exist)
Click to expand...
Click to collapse
Which device is still ARMv6 nowadays? joke aside, the x86 emulation was developed by Intel (so that their processor can compete on the smartphone market), a similar software is very unlikely to be written for armv6. It might be possible to use user-mode qemu to run armv7 libraries on armv6, but this will be terribly slow and for most apps the reason to use native code is that it should be faster than Java code, which will not be the case with such an emulation approach...

MaR-V-iN said:
The idea is to have a root system that works the opposite to what some su hiding tools do: the su binary is only available to certain apps the user preselected. This will also hide it to apps that should not see it. This way we can't have a nice "grant root permissions" dialog, but these are insecure nonetheless..
Click to expand...
Click to collapse
Although it is more secure it will kill user-friendliness and it will probably cause compatibility problems with old apps.
I sometime use also apps no longer updated and it wouldn't be nice to not be able to use them.
I think it would be better to support both modes and allow user to choose.
MaR-V-iN said:
What exactly do you want to simulate. The device name as returned by Build.MODEL? Note that it is technically impossible to simulate a whole other device in a way that can't be recognized
Click to expand...
Click to collapse
My intent is just to run apps that do run only on specific phones without change the app itself, I don't think they use a type of detection hard to bypass but I don't really know.
MaR-V-iN said:
Which device is still ARMv6 nowadays? joke aside, the x86 emulation was developed by Intel (so that their processor can compete on the smartphone market), a similar software is very unlikely to be written for armv6. It might be possible to use user-mode qemu to run armv7 libraries on armv6, but this will be terribly slow and for most apps the reason to use native code is that it should be faster than Java code, which will not be the case with such an emulation approach...
Click to expand...
Click to collapse
I know that it will be really slow but it still would be better than an app that crash at startup.
PS: Also it would be nice to have compatibility with cSploit.

ale5000 said:
Although it is more secure it will kill user-friendliness and it will probably cause compatibility problems with old apps.
I sometime use also apps no longer updated and it wouldn't be nice to not be able to use them.
I think it would be better to support both modes and allow user to choose.
Click to expand...
Click to collapse
For apps this will look as if you don't have root if you did not grant permission in advance through the system settings. The applications should not break because of this (but maybe just show you a message). Yes, it will be less user-friendly, but opening a critical hole in the security system should be nothing that is user-friendly. You usually do not have a lot of apps that require root access and to activate those manually in the system settings is not a huge problem. We would like to add features to the ROM like app data backup so that you need even less.

Well, for a normal user yes, but a normal user do not usually install a custom ROM.
I personally use a lot of apps that require root access.
Although it is probably not so easy I think it is possible to implement a dialog with tapjacking protection that ask if allow or deny root access.

ale5000 said:
Well, for a normal user yes, but a normal user do not usually install a custom ROM.
I personally use a lot of apps that require root access.
Although it is probably not so easy I think it is possible to implement a dialog with tapjacking protection that ask if allow or deny root access.
Click to expand...
Click to collapse
Even with all tapjacking techniques that are possible in Android (which would include a certain delay for the root usage confirmation to be tap-able), you can still use invoke keystrokes. This would allow a privilege escalation. When talking about security, don't argue with "I know what I do", it's not about you knowing what you do, it's about attackers knowing it as well.
The only effective way to protect against any type of tapjacking/input injection is to put everything completely aside (e.g. in the settings app) and protect it by requiring the user to enter his/her lockscreen key (or use fingerprint) before being able to change anything. While the ask about permission approach might be good enough for classic permissions (contacts/calender), it is not a good idea for something like root access, because it requires extreme caution.
Can you list the apps that require root which you are using? This would help a lot in finding out how important the root feature really is.

Related

[Q] Native C++ Access To Native Linux API Or Not?

This is my first post to XDA.
I have been asking this question about various OS's in various forums, for past 18 months, and each time I ask it, the person who answers it spends a few iterations with me bending-over-backwards trying to avoid telling me what I want to know. I hope that this does not happen here.
I have a native C++ application. It currently runs on Linux desktop. It does many things that native C++ applications do, including sending raw Ethernet frames (mesh networking).
Obviously, if one of my customers tries to install this application on his/her Android device, there will be problems, and it won't work.
I am aware that a human being has the ability to root his/her phone.
I am aware that a human being has the ability to root his/her phone.
I am aware that a human being has the ability to root his/her phone.
Please do not send me a reply saying, "But your customer has the ability to root his/her phone!" :cyclops:
What I would like, is a smartphone, that is running Linux, that allows my customer to install a 100% Native C++ application, >>>WITHOUT<<< having to go through the process of rooting his/her phone. Ideally, the barrier-to-installation would be roughly equivalent to what s/he would experience on a desktop computer.
I am not concerned about the presence of X or any particular GUI subsystem, but I will definitely need access to all the normal system-level Linux primitives (multi-threading, asynchronous I/O, etc.)
Please do not send me a reply saying, You can ssh into the phone and install the app that way."
I would like to know if Ubuntu on smartphone allows a relatively naive user to install a 100% native C++ application that interfaces with the system-level primitives of Linux.
And finally, please note that I am not interested in finding a work-around to an engineering problem that I am having. I am trying to determine the maximum permissible degree of nativity of Ubuntu Touch applications when the application is to be installed by a naive user.
If Ubuntu touch does allow such native applications to be installed, I would be interested in getting an idea of the steps that a customer would take.
UT apps can be uploaded as a click app to the UbuntuOne store and then can be installed as easy as any Android app. You should be able to "sideload" click apps, but I never tried.
UT apps - that are not a web app - are written in native C++ using QT5/QML for UI.
UT apps are restricted by apparmour profiles, but that should not keep them from using multithreading or asynchronous I/O. You would have to test, if your specific requirements work.
There is only one way to answer all your questions: give it a try!
Sent from my TF300T using Tapatalk
f69m said:
UT apps can be uploaded as a click app to the UbuntuOne store and then can be installed as easy as any Android app. You should be able to "sideload" click apps, but I never tried.
UT apps - that are not a web app - are written in native C++ using QT5/QML for UI.
UT apps are restricted by apparmour profiles, but that should not keep them from using multithreading or asynchronous I/O. You would have to test, if your specific requirements work.
There is only one way to answer all your questions: give it a try!
Sent from my TF300T using Tapatalk
Click to expand...
Click to collapse
:good:
Yes, you would need to change the packaging system from debian archives to click packages but that shouldn't be too difficult. If you run into problems with the Ubuntu SDK in connection with C++, have a look at this bug report and the mentioned fixes: https://bugs.launchpad.net/ubuntu/+source/qtcreator/+bug/1215913
f69m said:
UT apps can be uploaded as a click app to the UbuntuOne store and then can be installed as easy as any Android app. You should be able to "sideload" click apps, but I never tried.
Click to expand...
Click to collapse
Any idea at all what the user would see when trying to sideload a click app. [I am trying to set my expectations before diving in.] Would the user download package to a directory, then click on it, or?
UT apps are restricted by apparmour profiles, but that should not keep them from using multithreading or asynchronous I/O. You would have to test, if your specific requirements work.
There is only one way to answer all your questions: give it a try!
Click to expand...
Click to collapse
OK, apparmour seems to be the focal point. I would be really interested (if any knows), how restrictive apparmour will be with a newly-purchased UT phone, and what control a naive user of that phone will have in allowing native C++ applications to run. I would check this myself, but I cannot do any significant coding (porting) until mid-March.
In particular, my app works with WiFi, and will need to interact with stock WiFi drivers (mac80211/etc.). I would like to know what I, and the user, can expect when s/he:
acquires my app from my web site
does something to install it (what would s/he do at this step?)
attempts to execute it (will apparmour block access to mac80211-like drivers)
RareHare said:
Any idea at all what the user would see when trying to sideload a click app. [I am trying to set my expectations before diving in.] Would the user download package to a directory, then click on it, or?
OK, apparmour seems to be the focal point. I would be really interested (if any knows), how restrictive apparmour will be with a newly-purchased UT phone, and what control a naive user of that phone will have in allowing native C++ applications to run. I would check this myself, but I cannot do any significant coding (porting) until mid-March.
In particular, my app works with WiFi, and will need to interact with stock WiFi drivers (mac80211/etc.). I would like to know what I, and the user, can expect when s/he:
acquires my app from my web site
does something to install it (what would s/he do at this step?)
attempts to execute it (will apparmour block access to mac80211-like drivers)
Click to expand...
Click to collapse
Applications should be installed from the Ubuntu app store. If you've just got the click package, you currently need to use the command line to install it:
Code:
sudo install <path to package>
sudo register --user=phablet <package name> <package version>
I hope that this will change though. (It's name is "click" package. )
RareHare said:
Any idea at all what the user would see when trying to sideload a click app. [I am trying to set my expectations before diving in.] Would the user download package to a directory, then click on it, or?
Click to expand...
Click to collapse
nikwen said:
Applications should be installed from the Ubuntu app store. If you've just got the click package, you currently need to use the command line to install it:
Click to expand...
Click to collapse
Technically it should be possible to install a click package just by clicking on a web link, if the web site serves a specific mime type, but this is not implemented.
Not sure about Canonical's policy on that, they might not like the idea. Otherwise they might implement it or at least accept a patch from a community developer.
RareHare said:
OK, apparmour seems to be the focal point. I would be really interested (if any knows), how restrictive apparmour will be with a newly-purchased UT phone, and what control a naive user of that phone will have in allowing native C++ applications to run. I would check this myself, but I cannot do any significant coding (porting) until mid-March.
Click to expand...
Click to collapse
Sorry, have not looked myself into the apparmour profiles too closely and don't have the time to do that right now.
However you can download a recent UT rootfs using the link below and have a look at the profiles yourself:
https://system-image.ubuntu.com/pool/ubuntu-cd4246419c888397c0d8debbd9f945219f40fc670220b7ac86753dc79eb73707.tar.xz
RareHare said:
In particular, my app works with WiFi, and will need to interact with stock WiFi drivers (mac80211/etc.).
Click to expand...
Click to collapse
I don't think this is possible with any current or future off-the-shelf phone. Any OS will provide an abstract API for WLAN and require root to talk to the drivers directly.
As you say requiring your customers to root the phone is not an option, this seems to leave only one way out: you need to split off the low-level code of your app into a generic and secure API and submit it to Ubuntu Touch. If it is accepted, your app can use the new API.
f69m said:
Technically it should be possible to install a click package just by clicking on a web link, if the web site serves a specific mime type, but this is not implemented.
Not sure about Canonical's policy on that, they might not like the idea. Otherwise they might implement it or at least accept a patch from a community developer.
Click to expand...
Click to collapse
Of course, it would technically be possible. Recently, I read a Google Plus post on that topic. Here's the link. (The interesting part is in the comments. Read all of them. )
They said that they'll offer those options in the future.
f69m said:
Technically it should be possible to install a click package just by clicking on a web link, if the web site serves a specific mime type, but this is not implemented.
Not sure about Canonical's policy on that, they might not like the idea. Otherwise they might implement it or at least accept a patch from a community developer.[
Sorry, have not looked myself into the apparmour profiles too closely and don't have the time to do that right now.
Click to expand...
Click to collapse
I am in the same situation myself - I do not have enough time to experiment with apparmour, so I'm asking Ubuntu so that I do not have to search/guess.:victory:
I don't think this is possible with any current or future off-the-shelf phone.
Click to expand...
Click to collapse
So it would seem.
Any OS will provide an abstract API for WLAN and require root to talk to the drivers directly.
As you say requiring your customers to root the phone is not an option, this seems to leave only one way out: you need to split off the low-level code of your app into a generic and secure API and submit it to Ubuntu Touch. If it is accepted, your app can use the new API.
Click to expand...
Click to collapse
Well, the low-level code, in my case, is the WiFi drivers. Also, I cannot imagine submitting a new API to Ubuntu Touch every-time a new model for accessing system-level primitives arrive. That would essentially loop Canonical into all of our engineering processes.
Your last comment actually is the crux of the issue. It points to a policy question, not a technical one, and one for which the answer is yes or no. I would imagine that, at this point, Canonical already knows the answer...
Principle:
There are numerous situations where it is good for a native application to not be sand-boxed, but have the same access to the Linux subsystems as a user would have on Ubuntu Desktop. There are situations where the owner of the phone would be sophisticated and comfortable enough that s/he can decide for himself/herself whether an application should be allowed root access to the phone. A fellow engineer called this the "welded-hood" principle:
Do people prefer buying cars that have the hoods welded-shut?
Many people might, but there are a significant number who would prefer not. As it turns out, an automobile can dangerous if the person opens the hood and starts working on things that s/he should not be touching (no pun intended). In the case of the fuel and braking system, it can even be lethal. But in the end, it was decided that, since we are all liberated adults, it is better to allow the customer freedom-of-choice.
What we have, right now, is a situation where the "hoods" on all mobile devices are essentially welded shut. I think that is unfortunate, because there is a huge latent demand for mobile devices that "still have their hoods", but if the user chooses to open the hood, with they key word here being easily, that would be his/her prerogative.
By the default, the system should be sand-boxed, but the user should have a facility that allows him/her access to install some native, system-level applications, easily, just as a user is allowed to tap-off her break fluid or bleed the fuel-line if she so desires, even though there are many warnings about what could happen if the application is installed. The "open-the-hood" operation would come with warnings that the user can choose to ignore, with resulting consequences.
Question:
Will Ubuntu Touch allow the owner of an Ubuntu Touch phone to side-load a native C++ application that interfaces with the various existing WiFi drivers in Linux, if the user decides for himself/herself, that it is OK for the application to interface with such drivers?
I have a feeling that the answer is no, but I am asking here to make sure.
RareHare said:
I am in the same situation myself - I do not have enough time to experiment with apparmour, so I'm asking Ubuntu so that I do not have to search/guess.:victory:
So it would seem.
Well, the low-level code, in my case, is the WiFi drivers. Also, I cannot imagine submitting a new API to Ubuntu Touch every-time a new model for accessing system-level primitives arrive. That would essentially loop Canonical into all of our engineering processes.
Your last comment actually is the crux of the issue. It points to a policy question, not a technical one, and one for which the answer is yes or no. I would imagine that, at this point, Canonical already knows the answer...
Principle:
There are numerous situations where it is good for a native application to not be sand-boxed, but have the same access to the Linux subsystems as a user would have on Ubuntu Desktop. There are situations where the owner of the phone would be sophisticated and comfortable enough that s/he can decide for himself/herself whether an application should be allowed root access to the phone. A fellow engineer called this the "welded-hood" principle:
Do people prefer buying cars that have the hoods welded-shut?
Many people might, but there are a significant number who would prefer not. As it turns out, an automobile can dangerous if the person opens the hood and starts working on things that s/he should not be touching (no pun intended). In the case of the fuel and braking system, it can even be lethal. But in the end, it was decided that, since we are all liberated adults, it is better to allow the customer freedom-of-choice.
What we have, right now, is a situation where the "hoods" on all mobile devices are essentially welded shut. I think that is unfortunate, because there is a huge latent demand for mobile devices that "still have their hoods", but if the user chooses to open the hood, with they key word here being easily, that would be his/her prerogative.
By the default, the system should be sand-boxed, but the user should have a facility that allows him/her access to install some native, system-level applications, easily, just as a user is allowed to tap-off her break fluid or bleed the fuel-line if she so desires, even though there are many warnings about what could happen if the application is installed. The "open-the-hood" operation would come with warnings that the user can choose to ignore, with resulting consequences.
Question:
Will Ubuntu Touch allow the owner of an Ubuntu Touch phone to side-load a native C++ application that interfaces with the various existing WiFi drivers in Linux, if the user decides for himself/herself, that it is OK for the application to interface with such drivers?
I have a feeling that the answer is no, but I am asking here to make sure.
Click to expand...
Click to collapse
Well, your comparison is not quite correct. On most phones, there is a way for an educated user to open the hood. This is usually referred to as rooting the phone. Some companies will give you a tool to unlock the bootloader and thus open the hood easily, for others it is a little harder. But any user has the freedom of choice to open the hood or leave it closed.
Now, what you are asking for is something completely different. You are asking for a closed-source "black box" app to get access to what is under the hood, without the user ever opening it. This would mean opening the door for all kinds of malware, and I sure hope this will not be allowed by Ubuntu Touch . Let an educated user open the hood and place the black box there, if he feels comfortable about it, but don't make it too easy. A user that is not willing or not able to open the hood himself should also not be required to understand the consequences of installing a black box app with root privileges.
And there is another thing to consider: Ubuntu is heading for convergence, meaning the same app runs fine on a phone, on a tablet and on a desktop. This means apps must be written against an abstract SDK and not have access to the actual hardware.
Well, I am afraid we have hit a dead end now, unless you are willing to disclose more details on the functionality of your app.
Sent from my TF300T using Tapatalk
83594455 676
And there is another thing to consider: Ubuntu is heading for convergence, meaning the same app runs fine on a phone, on a tablet and on a
desktop. This means apps must be written against an abstract SDK and not have access to the actual hardware.
Click to expand...
Click to collapse
I think my native, system-level app would not only run on all versions of Ubuntu, regardless of device, but most versions of Linux, on 100's of different hardware devices, without changes to my code. So actually, I would be accessing a standard Linux software interface.
Well, I am afraid we have hit a dead end now, unless you are willing to disclose more details on the functionality of your app.
Click to expand...
Click to collapse
Sure. I would like to send and receive raw 802.11 frames from user-space utilizing the various standard Linux 802.11 system-level API's for mesh networking. My application is entirely user-space, and would run on any stock Linux kernel. My field of work is wireless communication, so naturally, if someone were to offer me a mesh-networking packaging as an alternative, I could not use it - my goal is not to have a mesh network for mesh networking sake, but to create a mesh network using my own user-space algorithms. In other words, I really do need access to the 802.11 drivers.
You can run every system command from your app using C++: http://askubuntu.com/questions/288494/run-system-commands-from-qml-app
The sudo password is "phablet". You could also ask the user for it if it was changed. You can pass it like this:
Code:
echo phablet | sudo -S <my command>
That might help you.
You could also ask in the IRC channel for Ubuntu app development (search the internet and you'll find it). Some Canonical people as well as some awesome community members will surely answer your questions. (But tell us the result, please.)
nikwen said:
You can run every system command from your app using C++: http://askubuntu.com/questions/288494/run-system-commands-from-qml-app
The sudo password is "phablet". You could also ask the user for it if it was changed. You can pass it like this:
Code:
echo phablet | sudo -S <my command>
That might help you.
Click to expand...
Click to collapse
That works for the development images and community ports, but I am afraid if you buy a pre-configured UT phone (once they are available), sudo will not work. At least I would be surprised if a company would give full warranty for a device with working sudo.
Sent from my TF300T using Tapatalk
---------- Post added at 11:14 PM ---------- Previous post was at 11:02 PM ----------
RareHare said:
I think my native, system-level app would not only run on all versions of Ubuntu, regardless of device, but most versions of Linux, on 100's of different hardware devices, without changes to my code. So actually, I would be accessing a standard Linux software interface.
Sure. I would like to send and receive raw 802.11 frames from user-space utilizing the various standard Linux 802.11 system-level API's for mesh networking. My application is entirely user-space, and would run on any stock Linux kernel. My field of work is wireless communication, so naturally, if someone were to offer me a mesh-networking packaging as an alternative, I could not use it - my goal is not to have a mesh network for mesh networking sake, but to create a mesh network using my own user-space algorithms. In other words, I really do need access to the 802.11 drivers.
Click to expand...
Click to collapse
Hmm, never really used the user-space network link interface, but I believe it would be possible to grant the required capabilities to a click application.
You would have to figure out, exactly what capabilities your process needs to run this as a non-root user. Then the right place to ask for supporting this would be the Ubuntu Phone mailing list.
Just a Tip: You should present a very strong use case to get this kind of capabilities. The benefits of using your user-space algorithms should be plain, even to someone just scanning over your email.
Sent from my TF300T using Tapatalk
f69m said:
That works for the development images and community ports, but I am afraid if you buy a pre-configured UT phone (once they are available), sudo will not work. At least I would be surprised if a company would give full warranty for a device with working sudo.
Click to expand...
Click to collapse
When nikwen made the suggestion, I was happy for maybe 2-3 seconds, but then caught myself, because I suspected this.
[Notice how I am saving myself enormous amounts of time and frustration by avoiding downloading the SDK, opening my compiler tool-chain, and experimenting., and discovering all the things that you are telling me as we go along (especially about apparmour). Yes, I am very proud of myself for saving myself so much time by asking questions here. :angel:]
So my question still stands:
Under the assumption that my customers (doctors, scientists, etc.) are mature/sophisticated/responsible/whatever enough to know that the application that they are about to install on their smartphone (mine) is potentially very dangerous, but they are still interested in installing my app, and that they are uninterested in going through the manual process of rooting their phone or engaging in any other type of significant manual reconfiguration, what are my options?
Can Ubuntu Phone to be the OS-of-choice for this situation, or am I out-of-luck?
RareHare said:
Under the assumption that my customers (doctors, scientists, etc.) are mature/sophisticated/responsible/whatever enough to know that the application that they are about to install on their smartphone (mine) is potentially very dangerous, but they are still interested in installing my app, and that they are uninterested in going through the manual process of rooting their phone or engaging in any other type of significant manual reconfiguration, what are my options?
Can Ubuntu Phone to be the OS-of-choice for this situation, or am I out-of-luck?
Click to expand...
Click to collapse
Maybe my second answer and your post crossed? But anyhow, here are the steps you can take:
1) Figure out the minimum set of capabilities your process needs to run as a non-root user.
2) Write an email to the Ubuntu Phone mailing list, describing the required capabilities and a convincing use case that motivates the engineers to have a hard look into it.
Honestly, I think the chances are slim, given the kind of capabilities you probably need. But Ubuntu Touch is probably your best bet of all the OSs out there.
EDIT: Mind that Ubuntu Touch uses a read-only rootfs, with only some config files being writable (via bind mount) and apt/dpkg is not supported. Your app must be running as a click package as a non-root user, but I believe it is technically possible to elevate an app process with certain capabilities. It would be your job to convince Canonical to make the policy decision to support it and to make the effort of implementing it.
EDIT2 (you see, I am giving it some thought): Not sure, how your business plan looks like or if your app makes this approach feasible, but another option could be to open-source your basic algorithms and try to have them included into Ubuntu Touch. Then cash in on an app to make the features easily accessible.
f69m said:
That works for the development images and community ports, but I am afraid if you buy a pre-configured UT phone (once they are available), sudo will not work. At least I would be surprised if a company would give full warranty for a device with working sudo.
Sent from my TF300T using Tapatalk
---------- Post added at 11:14 PM ---------- Previous post was at 11:02 PM ----------
Hmm, never really used the user-space network link interface, but I believe it would be possible to grant the required capabilities to a click application.
You would have to figure out, exactly what capabilities your process needs to run this as a non-root user. Then the right place to ask for supporting this would be the Ubuntu Phone mailing list.
Just a Tip: You should present a very strong use case to get this kind of capabilities. The benefits of using your user-space algorithms should be plain, even to someone just scanning over your email.
Sent from my TF300T using Tapatalk
Click to expand...
Click to collapse
Hm...it would be a bit weird for me to justify the benefits my user-space algorithms to Canonical. My app is not an open-source app. I guess I should have mentioned that first. In any case, I can say that I am "experienced" in this field, and my colleagues, at least, are experts in the field, so if the question is whether I am mistaken in thinking I need this capability, the answer is probably no.
However, you do have me intrigued regarding the granting of capability for a click application. My guess is that this would have to happen within the context of Ubuntu Store and not any other way or?
I ask because it is not yet definite that we will choose Ubuntu Phone. That is what I am determining now. I would hate to get into a situation where we have to "work with" Canonical to get access to the Linux API that we need, which is why I was suggesting putting the decision into the hands of the user. I would also like to avoid "lobbying" Canonical for a feature. It would be more efficient for us if Canonical would simply tell us whether they are going to allow it or not, to what extent, and what would be involved.
Again, what we are asking for is pretty straightforward - access to the standard Linux WiFi drivers from user-space.
There's really not much more to it. I was hoping that, based upon the assumption that we actually need this, that Canonical would be able to give us an answer.
[P.S. Yes, our posts got crossed. ]
RareHare said:
Hm...it would be a bit weird for me to justify the benefits my user-space algorithms to Canonical. My app is not an open-source app. I guess I should have mentioned that first.
Click to expand...
Click to collapse
Well, I somehow guessed it would not be open source, and probably my EDIT2 to my last post (crossed again) is not an option. But make sure to read my first EDIT, it might have helpful information.
I think the question is not, if it is a benefit to Canonical directly, but if it is a benefit to potential users of Ubuntu Touch. The API support you need might be helpful for other applications too.
RareHare said:
However, you do have me intrigued regarding the granting of capability for a click application. My guess is that this would have to happen within the context of Ubuntu Store and not any other way or?
I ask because it is not yet definite that we will choose Ubuntu Phone. That is what I am determining now. I would hate to get into a situation where we have to "work with" Canonical to get access to the Linux API that we need, which is why I was suggesting putting the decision into the hands of the user. I would also like to avoid "lobbying" Canonical for a feature. It would be more efficient for us if Canonical would simply tell us whether they are going to allow it or not, to what extent, and what would be involved.
Click to expand...
Click to collapse
Any decision taken by the user must first be implemented by Canonical, or there is no way for the user to make that decision. Unfortunately, I am not an expert on UT app development and the UT SDK, working mostly on low-level things like porting UT to my own device. But, as an example, it should be possible to have an API that creates a sub-process with elevated capabilities (there might be a more elegant solution). Still Canonical will have to implement that and to do this, they need some kind of motivation. The motivation could be a good use case that shows potential for other applications or indeed "lobbying" them directly (which probably means to send them some money).
RareHare said:
Again, what we are asking for is pretty straightforward - access to the standard Linux WiFi drivers from user-space.
There's really not much more to it. I was hoping that, based upon the assumption that we actually need this, that Canonical would be able to give us an answer.
Click to expand...
Click to collapse
I have not really used those APIs, but I assume that the kernel capabilities needed for this are usually granted to the root user only. I am pretty certain that UT will not allow you to run a process as root, but as mentioned above, it should be possible to create a subprocess with certain elevated capabilities.
f69m said:
Well, I somehow guessed it would not be open source, and probably my EDIT2 to my last post (crossed again) is not an option. But make sure to read my first EDIT, it might have helpful information.
Click to expand...
Click to collapse
OK.
f69m said:
I think the question is not, if it is a benefit to Canonical directly, but if it is a benefit to potential users of Ubuntu Touch. The API support you need might be helpful for other applications too.
Click to expand...
Click to collapse
Well, the API that I need is definitely helpful for other applications. Namely, it is helpful to any application that already uses it. And there are many such applications that use the 802.11 WiFi drivers that come with Linux.
Any decision taken by the user must first be implemented by Canonical, or there is no way for the user to make that decision. Unfortunately, I am not an expert on UT app development and the UT SDK, working mostly on low-level things like porting UT to my own device. But, as an example, it should be possible to have an API that creates a sub-process with elevated capabilities (there might be a more elegant solution). Still Canonical will have to implement that and to do this, they need some kind of motivation. The motivation could be a good use case that shows potential for other applications or indeed "lobbying" them directly (which probably means to send them some money).
I have not really used those APIs, but I assume that the kernel capabilities needed for this are usually granted to the root user only. I am pretty certain that UT will not allow you to run a process as root, but as mentioned above, it should be possible to create a sub-process with certain elevated capabilities.
Click to expand...
Click to collapse
OK.
I am going to send an email to Canonical asking if they could articulate, clearly, in a manner that a Linux C/C++ software engineer can understand, their policy on native application development. Here's what it currently says on their Wiki:
Which applications do run on Ubuntu Touch?
Ubuntu Touch is primarily designed to support web apps, and native apps programmed in qml and javascript or C++. As it is a real linux, of course all non graphical applications run equally as on any other linux system. You can ssh to Ubuntu Touch and run any console based application.
X11 is not supported (so far) so all GUI standard applications will not run.​
This is slightly confusing, because it gives the impression that, with the exception of X11, the run-time environment on Ubuntu Touch is equal to the run-time environment on Ubuntu Desktop.
Obviously, that is not true. Native applications on Ubuntu Touch are sand-boxed. My customer can run a console app on Ubuntu Desktop just fine, but on Ubuntu Touch, she cannot not - I guess she could if she rooted or re-flashed her phone, but that is not practical.
I think Canonical should make it clear that native C/C++ applications on Ubuntu Touch will be sand-boxed. Then they should articulate, clearly on their web site, just how that works, at least the part that they know so far.
The reason I feel this is necessary is that there are a lot of developers who read the press releases and see the words open source native C/C++, more open than Android, etc...and they get the impression that it is basically Ubuntu Desktop for small form-factor, but that is not quite true.
Spelling-out, explicitly, Canonical's native C/C++ strategy would save such developers a lot of time and hacking trying to figure out what is feasible and what is not.
To be fair, I just received feedback from a competitor to Ubuntu Touch, giving me assurances that the competing OS will allow the user/owner of the phone to determine whether any software should have root access, etc - basically, like the desktop version of the OS. I will send them an email asking them if they could make public what they have assured me in private.
These are things that should be crystal clear to C/C++ software developers long in advance before committing to a platform. I can only imagine the time that would have been lost if I had misinterpreted what Canonical wrote above, only to find out that there is nothing practical that my customer can do to install my application as easily as they would on Ubuntu Desktop because of the sandbox that cannot be easily turned-off.
RareHare said:
I think Canonical should make it clear that native C/C++ applications on Ubuntu Touch will be sand-boxed. Then they should articulate, clearly on their web site, just how that works, at least the part that they know so far.
Click to expand...
Click to collapse
Of course I can't speak for Canonical and I might be wrong, but I would really be surprised, if it was possibly to run applications as root on an off-the-shelf Ubuntu Touch device.
RareHare said:
To be fair, I just received feedback from a competitor to Ubuntu Touch, giving me assurances that the competing OS will allow the user/owner of the phone to determine whether any software should have root access, etc - basically, like the desktop version of the OS. I will send them an email asking them if they could make public what they have assured me in private.
Click to expand...
Click to collapse
Interesting, but then it might be a difference between the "reference" implementation and what is being delivered on an out-of-the-shelf phone. I can't belive a device vendor to take the risk of allowing root access and still providing full warranty. Most likely the user will have to accept a "no warranty" waiver to get root access, if that feature is not completly disabled by the device vendor. The same kind of holds for UT, as sudo works on the development images as mentioned previously.
EDIT: Make sure the feedback you received does refer to an actual device that is/will be available for sale and not to a development platform. Marketing wording can be tricky about simple issues like that,
RareHare said:
These are things that should be crystal clear to C/C++ software developers long in advance before committing to a platform. I can only imagine the time that would have been lost if I had misinterpreted what Canonical wrote above, only to find out that there is nothing practical that my customer can do to install my application as easily as they would on Ubuntu Desktop because of the sandbox that cannot be easily turned-off.
Click to expand...
Click to collapse
Agreed, but the same holds for any other platform.
f69m said:
Of course I can't speak for Canonical and I might be wrong, but I would really be surprised, if it was possibly to run applications as root on an off-the-shelf Ubuntu Touch device.
Interesting, but then it might be a difference between the "reference" implementation and what is being delivered on an out-of-the-shelf phone. I can't belive a device vendor to take the risk of allowing root access and still providing full warranty. Most likely the user will have to accept a "no warranty" waiver to get root access, if that feature is not completly disabled by the device vendor. The same kind of holds for UT, as sudo works on the development images as mentioned previously.
Agreed, but the same holds for any other platform.
Click to expand...
Click to collapse
I was very careful in asking the UT-competitor what their policy would be with regard to the subject of this thread, and they assured me that, when they say open, they really do mean open, as in open-like-the-desktop. However, just now, I found clues on the Internet what they said might not be quite true. So I just sent a grab-me-by-the-ears-while-you-are-speaking email asking them to be clear.
However, they have committed to allowing the user to install my application. They know that my application will open a device driver, and they said that it should work fine, that they would allow the user to do it, and that they had already intended to create a feature where the user gets to decide, after a WARNING, though they are not yet certain what this feature will be called. Note that they are not doing this for me alone. They are doing it, in general. In other words, they are doing what I proposed earlier: give the user the choice of whether to "use metal chainsaw".
As far as voiding the warranty goes...honestly, I do not think that will be a problem. As you know, I can write software that will wipe my hard disk clean on Windows, right now, put it up on my web site, and anyone in the world can download that software, and the most that will happen before they install my application is that they will get a brief warning. So the model for allowing the user to do foolish things has been with us for a while, and companies are still very profitable with this model, and despite viruses (I developed anti-virus algorithm that some of you use, btw), most people are happy with the level-of-control they get with their desktop devices. When Windows Vista tried to remove some of it, even moderate users were very angry, as you know.
I think that, especially for cell-phone carriers in the USA (Verizon, AT&T, Sprint)...the reason is not so much to protect the consumer, but to make sure that the user is not able...for example...to remove the bloatware that they put on the phone. It is more about controlling the customer experience for profit than for protection or being liable for damages.
The UT-competitor has probably figured out that there is a market for a truly open mobile platform, one where the decision of what happens to the device reverts to the owner of the device. They are probably counting on all the pent-up demand of C/C++/etc. native software developers who have been trying to escape the Android/Java iOS/* Sandbox, and not only that, the developers who are able to create revolutionary innovations if they had more access to the Linux API. My guess is that, once one OEM takes this path, the others will not have any choice but to follow, because there will be a free-for-all (no pun intended) in the development market. It will be messy, perhaps, but there will no longer be any restrictions on getting the most out of the device.
It will definitely be more efficient to decouple development from deliverance.
Well, sounds good, just hope that they will find an OEM that shares their views. I think Desktop/Windows is not a relevant reference, as nobody will send their PC back to Microsoft, if it is not working. And if you want to use official MS support you are paying dearly. On the other hand support/warranty is a huge concern for phone and tablet vendors.
Again, not being able to run a process as root on a UT device is my personal opinion and I am not speaking for Canonical or their partners.
EDIT: Do the "bad" operations you mentioned work on Windows 8 phone? I suppose not.
Sent from my TF300T using Tapatalk

Android 7.1 Restricted Accounts

I am looking to move to an android phone and I need one that has the ability to have restricted accounts, similar to what was introduced on tablets with 4.2 or what iphones have, where you have a password protected way of enabling or disabling different applications. I have seen a program called applock on Android that attempted this, but it had a severe flaw that made it easy to bypass. Is anyone aware of a custom rom that enables this, or perhaps a modification to build.prop that would enable it?
webbwbb said:
I am looking to move to an android phone and I need one that has the ability to have restricted accounts, similar to what was introduced on tablets with 4.2 or what iphones have, where you have a password protected way of enabling or disabling different applications. I have seen a program called applock on Android that attempted this, but it had a severe flaw that made it easy to bypass. Is anyone aware of a custom rom that enables this, or perhaps a modification to build.prop that would enable it?
Click to expand...
Click to collapse
Try MIUI ROM.
randomx1 said:
Try MIUI ROM.
Click to expand...
Click to collapse
Does it allow you to disable things like the play store and system browser? I am trying to get a good, child proofed phone.

What are the benefits or rooting

This could be a general question for all Android phones.
It seems that Google is making it more difficult to root with every release of Android . If you do manage to root, sometimes you lose functionality unless you manage to find a workaround.
In years gone by, there were good reasons to root because Android was missing a lot of useful features that developers were able to implement on rooted devices but Android has improved a lot and Google has implemented a lot of the functionality that previously required root and customs ROMS.
So my question is what are the real benefits of rooting the Moto Z and rooting in general?
Still mandatory
1) Access to hosts-file for ad-blocking and other security purposes.
2) Ability to remove bloatware installed as system apps by vendor or manufacturer.
3) Use of firewalls, filters and stuff on network level
4) Granulated right management like "deny location", "deny network state" and stuff - per App.
As long as even only one of these access rights is not available on non-rooted Android, rooting is mandatory.
By the way: And at least 1)+4) was MY reason not to buy the Blackberry PRIV, which could have been perfect for me by means of design, look-and-feel, specs... if it was rootable. And that´s contrary to BB´s intentions. Sad, so sad... :>
Now Moto Z: Happy, so happy!
Also:
- Customize UI (I use battery bar, seconds in status bar, up-/downloadspeed, blurring background on expanded notification bar)
- when possible (atm only with marshmallow, not nougat or later) Xposed with a number of modules [not SafetyNet compatible... other say that, I was able to use it with suhide on my old phone]
- Viper4Android (sound equalizer for the whole system)
- Greenify
- and a few more
- works with SafetyNet
To put it simply.
fULl cOnTROOOoOL
omnomnomkimiiee said:
To put it simply.
fULl cOnTROOOoOL
Click to expand...
Click to collapse
Those are all great reasons to root. One more reason that I find gives me peace of mind is the ability to do actual backups. Titanium backup and even nandroid backups (which kind of go along with rooting) are great for making sure you don't lose any important information or settings.

How can I learn how Android works?

I'm not a developer but I have knowledge about Linux and how PCs in general work. Is there any book/course that explains how android works on a deeper level? I'm not interested in apps or user UIs, I want to know the deeper levels like how partitioning works, how the OS is loaded, why some bootloaders are locked by default, what a custom recovery is or what is the first thing to load when you power on your phone/tablet (do phones have a BIOS like PCs or anything equivalent?). Thanks in advance.
I'm also interested in this, but I think the answer is it's a bunch of undocumented proprietary baseband processor junk nobody will share for the boot, then the rest is basically a Linux distro made by 1000 monkeys on 1000 typewriters copy/pasting stuff provided by their hardware vendors together, and the components of that also probably have no documentation or incorrect documentation.
Just browsing through directory structures on a rooted phone there's so much unused and inaccessible junk like config files for really old versions of android, random vendor apks that aren't configured, and firmware for other processors strewn all over, sometimes multiple copies of the same structure, that it makes no sense. It looks like a bunch of vendors gave their support libraries to manufacturers with the intent they'd delete the unused parts and copy the used parts in, but the manufacturers don't understand how to do that so they just paste the same full directory structure several different places until it starts working.
If it made any sense, some people would just learn it and rooting new phones wouldn't be hard.
dan2525 said:
I'm not a developer but I have knowledge about Linux and how PCs in general work. Is there any book/course that explains how android works on a deeper level? I'm not interested in apps or user UIs, I want to know the deeper levels like how partitioning works, how the OS is loaded, why some bootloaders are locked by default, what a custom recovery is or what is the first thing to load when you power on your phone/tablet (do phones have a BIOS like PCs or anything equivalent?). Thanks in advance.
Click to expand...
Click to collapse
The rabbit hole goes as deep as you want it to. I have plenty of information to get you started. Happy digging!
*A general overview of the android boot process, thanks to the Lineage OS developers.
*An old, but good read on reverse engineering aboot.
*And a much more recent article on reverse engineering android. It gets very detailed in this one. It also goes into the low level processes of android. Like; What loads the bootloader? That kind of stuff. I think this is what you're after. Hope it helps.
About the bios question. The short answer is, "kind of". They have a very simple and proprietary one that's not easy to access. It also does not function in the same ways that a PC bios does. It's more like a motherboard programmer. It's hard to explain. The last article goes into some of that.
Spaceminer said:
The rabbit hole goes as deep as you want it to. I have plenty of information to get you started. Happy digging!
*A general overview of the android boot process, thanks to the Lineage OS developers.
*An old, but good read on reverse engineering aboot.
*And a much more recent article on reverse engineering android. It gets very detailed in this one. It also goes into the low level processes of android. Like; What loads the bootloader? That kind of stuff. I think this is what you're after. Hope it helps.
About the bios question. The short answer is, "kind of". They have a very simple and proprietary one that's not easy to access. It also does not function in the same ways that a PC bios does. It's more like a motherboard programmer. It's hard to explain. The last article goes into some of that.
Click to expand...
Click to collapse
Do you know if there is any tool that lists all the various initscripts and settings in use on a running system? I'd like to remove Google entirely from my phone, but there are so many firmwares and initscripts all over the place that I can't even figure out which ones are actually used to run the system. Half of the settings files, properties, and commands return 0 results or 3-4 useless results when searching for them on the internet.
ZHNN said:
Do you know if there is any tool that lists all the various initscripts and settings in use on a running system? I'd like to remove Google entirely from my phone, but there are so many firmwares and initscripts all over the place that I can't even figure out which ones are actually used to run the system. Half of the settings files, properties, and commands return 0 results or 3-4 useless results when searching for them on the internet.
Click to expand...
Click to collapse
The best way to remove google entirely is to flash a custom ROM or GSI if your device supports it. You really only need to look in system/app and system/priv-app for google stuff. Some phones use stock Google apps for things like the Calendar or MMS. So, to run google-less you may need to replace some system apps as well. Just a warning, even if you already know this. Removing certain apps, even google apps, may cause problems for normal operation. Definitely make a backup before deleting anything in the system.
ZHNN said:
Do you know if there is any tool that lists all the various initscripts and settings in use on a running system? I'd like to remove Google entirely from my phone, but there are so many firmwares and initscripts all over the place that I can't even figure out which ones are actually used to run the system. Half of the settings files, properties, and commands return 0 results or 3-4 useless results when searching for them on the internet.
Click to expand...
Click to collapse
I'm no expert but have been running lineageos 14.1 for some time now. It is a version of android 7.1 in which everything google has been removed. I use it with microG which replaces google play services.
You may wish to look into it instead of re-inventing the wheel.
I use it with a firewall (AFWall +), and Xprivacylua for additional privacy.

How To Guide Use german banking apps with root

I decided to root ky Pixel 6 and found out that i couldn't get around the security from germans banking apps.
simple soloution. have magisk/zygisk installed and set the root mode to "user" in the settings of magisk manager.
then go to your settings and setup a second user (wont have root) install your banking apps and enjoy the ability to use them with an rooted device
edit: this method was tested for Sparkasse app's
• S-Push Tan
• Mobiles Bezahlen
IndubidablyStoned said:
I decided to root ky Pixel 6 and found out that i couldn't get around the security from germans banking apps.
simple soloution. have magisk/zygisk installed and set the root mode to "user" in the settings of magisk manager.
then go to your settings and setup a second user (wont have root) install your banking apps and enjoy the ability to use them with an rooted device
Click to expand...
Click to collapse
I'm not being critical of your choices but why would anyone chance having a banking institution or any financial app including
GPay on a rooted device? Isn't there a much greater chance of being compromised by an app or inadvertent web link? And if the banking institution sees that a bogus user was created what are the chances of recovering funds obtained through fraudulent activity? I understand why people want to root don't get me wrong, but money transfers and transactions on that device seem a little reckless to me. But I could be wrong, just curious of the thinking here.
i Understand, but if you want to have an custom DAC like Viper4Android you kinda need root. my intention isnt to do fraudulent activity, as i mentioned in the Post you dont have Root access on that second user
IndubidablyStoned said:
i Understand, but if you want to have an custom DAC like Viper4Android you kinda need root. my intention isnt to do fraudulent activity, as i mentioned in the Post you dont have Root access on that second user
Click to expand...
Click to collapse
You misunderstood my concern wrt banking activity. I didn't suggest that you were doing anything fraudulent but if you were the victim of fraudulent activity would the bank still cover you with a bogus account you created? I don't know if what you did was entirely proper or not but that was not the issue I thought you might be concerned about.
As I said, I completely understand your desire to root be it V4A or DAC or even ad blocking. I just wonder the benefit vs the exposure if you are using banking apps. Without financial transactions occurring on the phone I doubt there is much to worry about other than what we are all concerned about root or not.
bobby janow said:
I'm not being critical of your choices but why would anyone chance having a banking institution or any financial app including
GPay on a rooted device? Isn't there a much greater chance of being compromised by an app or inadvertent web link? And if the banking institution sees that a bogus user was created what are the chances of recovering funds obtained through fraudulent activity? I understand why people want to root don't get me wrong, but money transfers and transactions on that device seem a little reckless to me. But I could be wrong, just curious of the thinking here.
Click to expand...
Click to collapse
Considering DirtyPipe exists and has not been patched yet (plus how long it already took to even acknowledge the problem in the first place), rooting is the least of our worries when it comes to monetary transactions/banking and android.
Bear in mind that DirtyPipe is only one elevation exploit that we've heard about. And for every disclosed vulnerability there are dozens of others that nobody's aware of. The market for rooted android users is very small compared to the overall android phone-user market. Creating exploits specifically targeting rooted phones would be a waste of time and effort compared to working on privilege escalation on non-rooted devices; from a hacker's perspective you want to hit the largest volume of targets in cases like these.
I've been rooting my phones for 10 years now, and my usage of banking/fintech apps on my devices has increased consistently. Applying common sense opsec/infosec practices can negate a large percentage of the perceived risk that root access exposes you to.
On the other hand, if someone wants to target you specifically, as an individual, you're screwed, root or no root, unless you're aware of the risks that come with technology and the pitfalls of android (iOS can be perceived as more secure but when it comes to individual targeting/attacks, there are expensive tools made by some of the world's top intelligence organizations that can wreck havoc on iOS as well)
TL;DR you're never truly safe, root or no root.
Unfortunately that doesn't worked for me
I tested the following apps:
SecureGo
VR SecureGo
Mobiles bezahlen
Every App doesn't launch. Sparkasse is quitting instantly and SecureGo Apps are stuck with their logo.
On the rootet user I get the Browser-warning (of SecureGo) that my device doesn't meet the security requierements. So far so good, but on the non-rooted uses i would have expect that they're working.
Any Idea? I'm on April Build.
i dont know currently, i dont have root anymore since i had to update to the April Update. i'll update if there is something that can be done
Maybe you could confirm that these Apps launch on April build without root? That could help to research the problem a bit. Thanks!
hanni2301 said:
...but on the non-rooted uses i would have expect that they're working.
Any Idea? I'm on April Build.
Click to expand...
Click to collapse
Maybe these apps are not supporting fully Android 12?
I have an app which, until recently, was freezing when the location was enabled. To be exact, when "Use precise location" was enabled. Only location access the app was not freezing, but couldn't get the coordinates.
Maye this is a similar situation here.
Cheers
Tom
hanni2301 said:
Unfortunately that doesn't worked for me
I tested the following apps:
SecureGo
VR SecureGo
Mobiles bezahlen
Every App doesn't launch. Sparkasse is quitting instantly and SecureGo Apps are stuck with their logo.
On the rootet user I get the Browser-warning (of SecureGo) that my device doesn't meet the security requierements. So far so good, but on the non-rooted uses i would have expect that they're working.
Any Idea? I'm on April Build.
Click to expand...
Click to collapse
I managed to get the VR Secure Go app working by doing the steps in the op plus using ice box and freezing magisk and the bank apps. I'm on April, too and I'm using radioactive kernel. Rooted stock kernel works as well on my device, but I had issues with the bank apps on some other kernels.
So to confirm, you need to freeze magisk on the rooted user and you're able to use the bank apps on the second (non rooted) user?
On which user you would freeze the bank apps? I doesn't have them installed on the rooted user.
Thanks in advance that you can definitely confirm its not the fault of April built.
hanni2301 said:
So to confirm, you need to freeze magisk on the rooted user and you're able to use the bank apps on the second (non rooted) user?
On which user you would freeze the bank apps? I doesn't have them installed on the rooted user.
Thanks in advance that you can definitely confirm its not the fault of April built.
Click to expand...
Click to collapse
I only have one user (the rooted user). I've done the following steps:
1. Configure magisk: activate Zygisk and setup deny list for the banking apps
2. Hide magisk app
3. Freeze magisk and banking apps with Ice Box
ok, that is the normal way which is different to the approach the thread starter has chosen.
I use deny list plus hide my applist and works fine with Sparkasse, s-push and mobil bezahlen no need to freeze or use a second user profile
How do you do that, hide applist?
You can bypass it by
Download App Named Shelter from Play store.
The App will create work profile and you can bypass any bank or app you facing issue with it.
When completed create work profile you can clone Bank App and use if.
As Information, It works out of the Box with Magisk denylist,
You only need to Install Ice Box and hide Magisk Manager, even if it is using a random name, "Mobiles Bezahlen" would detect it.
Magisk + Ice Box is sufficient on latest Miui 13 as well!
Regards!
Not sure but I think island could help not sure though as I'm not rooted the app is made by greenify
Only as info, these 2 Apps, Postbank Finanzassistent and Postbank BestSign working by default on a rooted device.
I like Postbank

Categories

Resources