Attend XDA's Second Annual Developer Conference, XDA:DevCon 2014!
5,741,743 Members 43,485 Now Online
XDA Developers Android and Mobile Development Forum

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

Tip us?
 
RareHare
Old
#1  
Junior Member - OP
Thanks Meter 1
Posts: 14
Join Date: Apr 2013
Sign [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.
  1. I am aware that a human being has the ability to root his/her phone.
  2. I am aware that a human being has the ability to root his/her phone.
  3. 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!"

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.
 
f69m
Old
#2  
Senior Member
Thanks Meter 400
Posts: 511
Join Date: Feb 2013
Location: Munich
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
 
nikwen
Old
#3  
nikwen's Avatar
Recognized Contributor
Thanks Meter 1298
Posts: 2,690
Join Date: Feb 2013
Quote:
Originally Posted by f69m View Post
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


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/+s...r/+bug/1215913
 
RareHare
Old
#4  
Junior Member - OP
Thanks Meter 1
Posts: 14
Join Date: Apr 2013
Quote:
Originally Posted by f69m View Post
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.
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?

Quote:

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!
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:
  1. acquires my app from my web site
  2. does something to install it (what would s/he do at this step?)
  3. attempts to execute it (will apparmour block access to mac80211-like drivers)
 
nikwen
Old
#5  
nikwen's Avatar
Recognized Contributor
Thanks Meter 1298
Posts: 2,690
Join Date: Feb 2013
Quote:
Originally Posted by RareHare View Post
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:
  1. acquires my app from my web site
  2. does something to install it (what would s/he do at this step?)
  3. attempts to execute it (will apparmour block access to mac80211-like drivers)
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:
Select 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. )
 
f69m
Old
(Last edited by f69m; 24th February 2014 at 11:16 AM.)
#6  
Senior Member
Thanks Meter 400
Posts: 511
Join Date: Feb 2013
Location: Munich
Quote:
Originally Posted by RareHare View Post
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?
Quote:
Originally Posted by nikwen View Post
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:
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.

Quote:
Originally Posted by RareHare View Post
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.
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...eb73707.tar.xz

Quote:
Originally Posted by RareHare View Post
In particular, my app works with WiFi, and will need to interact with stock WiFi drivers (mac80211/etc.).
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.
 
nikwen
Old
#7  
nikwen's Avatar
Recognized Contributor
Thanks Meter 1298
Posts: 2,690
Join Date: Feb 2013
Quote:
Originally Posted by f69m View Post
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.
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.
The Following User Says Thank You to nikwen For This Useful Post: [ Click to Expand ]
 
RareHare
Old
#8  
Junior Member - OP
Thanks Meter 1
Posts: 14
Join Date: Apr 2013
Quote:
Originally Posted by f69m View Post
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.
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.
Quote:
I don't think this is possible with any current or future off-the-shelf phone.
So it would seem.
Quote:
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.
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.
 
f69m
Old
#9  
Senior Member
Thanks Meter 400
Posts: 511
Join Date: Feb 2013
Location: Munich
Quote:
Originally Posted by RareHare View Post
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.

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.
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
 
RareHare
Old
#10  
Junior Member - OP
Thanks Meter 1
Posts: 14
Join Date: Apr 2013
Default 83594455 676

Quote:
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.
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.

Quote:
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.
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.

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes