Replicant

Got everything set up to do the job.
I'm expecting to start working on it in one week. This doesn't guarantee any successful or quick resolution, though.

Debugging Android Java framework in Eclipse works well enough, following this tutorial and this one
Thanks to that I'm now working on the issue fast and comfortably enough, and I'm now able to say that workarounds are definitely possible.
What I plan to do is create a subclass of NetworkInfo, designing it to specifically report the connection created via RepWifi, and override the default behaviour of the "proxy" methods in ConnectivityManager so that if a wifi connection on interface wlan0 is active, it gets added to the ones returned by the underlying system service.
This workaround should be enough to intercept the vast majority of Apps querying the system for connectivity status.

A deeper (and smarter) fix would need investigating the inner workings of the underlying system services, which can be done, but requires time and concentration, and I currently lack both, unfortunately.
So I will limit myself in putting up the aforementioned workaround, for now.

To summarize, I'm very optimistic about overcoming this issue.
Updates are coming.

Just a quick update.
It works.
Changes to the "ConnectivityService" do compile, and they do work as expected.
I was able to have F-Droid update the repos via the wifi connection established by RepWifi.
So, yes. It can be done.
In the upcoming days, I'll be working on cleaning up my test code, to make it suitable for production.

Good GNUs, everybody!
Everything works here!

• Added an internal class RepWifiConnection to the class NetworkInfo, under frameworks/base/core/java/android/net.
• RepWifiConnection has a static method getNetworkInfo that returns an instance of NetworkInfo, whose internal state is set up according to the state of the connection created via RepWifi.
• The connection state is determined inside RepWifiConnection by issuing the following shell commands:
  

  ip link

  determines whether the dongle is plugged in or not, which translates to the NetworkInfo instance being "avalable" or not.
  

  pidof wpa_supplicant

  determines if wpa_supplicant is running. If it's not, then the NetworkInfo instance is presented as DISCONNECTED.
  

  ip route

  determines whether a route for the interface wlan0 exists. If a route exists, and it has a gateway, then the NetworkInfo instance will be presented as CONNECTED.

• Added a public static method getRepWifiNetworkInfo to the NetworkInfo class, which is a proxy to expose the internal method RepWifiConnection.getNetworkInfo.

• Modified the ConnectivityService class under frameworks/base/services/core/java/com/android/server, updating the method getActiveNetworkInfo which is the one that gets called in most cases when apps query for the connection state. I added a call to NetworkInfo.getRepWifiNetworkInfo(), performed only if the default behaviour is returning no connection, otherwise the default behaviour is preserved.

ConnectivityService is the system service that answers queries about the network state coming from the Apps.
In most cases the method that gets called under the hood is getActiveNetworkInfo which I modified as reported above.

The resulting behaviour of the system service is the following (tested with F-Droid, clicking on the "update repos" button):
- when the wifi dongle is unplugged, ConnectivityService reports no connections, so F-droid shows "Cannot update. Are you connected to the internet?"
- the same happens when the dongle is plugged, but no connection has been established via RepWifi.
- when the dongle is plugged AND RepWifi has successfully put up a connection, then ConnectivityService returns to F-Droid a valid NetworkInfo instance whose state is set as CONNECTED. As such, F-Droid doesn't complain any more, and succeeds updating the repos, happily using the RepWifi connection.
- F-Droid is even able to download and install apps using the RepWifi connection (but this used to work even before).

I tried to keep modifications as compact as possible, which makes it easy to remove them and restore the "original" behaviour.

Now things must be tidied up a bit and get packed nicely.
Then some more test cases need to be brought up.
In theory the vast majority of the apps out there should be covered by these modifications, but I only tested them against F-droid, because I don't know of any other app that refuses to work well with RepWifi.

If anybody knows anything about other apps presenting the same issue, please let me know, so that I can test them to make sure they work fine with my methods.

I'm then going to submit a patch immediately after a few successful tests.

I did introduce some other adaptations to NetworkInfo, in order to include support for reverse-tethering.
Basically the same things explained for the connection established by RepWifi apply for the connection established via the reverse-tether scripts.

Now I have everything ready for a patch.
I'm struggling with git to make it spit out the needed diff file, but for the rest, everything is ready.

I put up a patch, and submitted it to the mailing list.
Correctly, Wolfgang Wiedmeyer pointed out some things to be changed both on the security and the coding style side..

I've been unable to work on that during the last two months, but I'm planning to do all the restyling before September..
Stay tuned!

It's done!

I've completely rebased my solution to comply to Wolfgang's sensible concerns about my previous patch.
In details:
I've removed all calls to shell commands, in order to improve reliability, security, maintainability and portability.
Everything is now pure Java, making use of the java.net.NetworkInterface class.
There's much less code involved (aprox. 55 lines vs. 250+), so that the impact on the original framework is lighter.

The groundings are basically the same as before:
when apps call getActiveNetworkInfo() on the ConnectivityManager, it looks down the usual path to retrieve "standard" connections.
If no "standard" connection is found, there comes my additional code:
java.net.NetworkInterface.getByName() gets called, looking for either "wlan0" (RepWifi) or "rndis0"(Tethering).
If any one of the two interfaces is present, getInetAddresses() is called on it, to see if it has any IP address.
If the interface has an IP address in the "local" range (e.g. 192.168.x.x), then it is considered connected. So an instance of android.net.NetworkInfo is created, and its state is set as "Connected".
Finally, that instance gets returned to the caller.

The result is that user-space apps are now able to "see" the internet connection made via RepWifi or via reverse tethering.

I tested the whole thing with "F-Droid" and "OpenVPN for Android", which were two known cases to solve.
The solution should be pretty "general-purpose", so I expect quite every app to work happily with it.

What I think of as the best achievement is that the new solution doesn't need any intervention on the public API.
Everything is preserved on the public side, so that "masters" at LineageOS are happy :)

What else to say..
Everything is done. It builds just fine. It runs smooth. It does the job and does it quite well.

I'm packing the patch right now, and hope it could get merged soon :)

Fil, thank you very much for the patch!
I attached the patch with my Reviewed-by and a few minor formatting improvements. I added line breaks to the commit message, removed a few minor whitespace errors and moved the changelog below the --- separator, so it's not included when the patch is applied. If you agree with the patch in this form, then I'll push it.

The Issue is solved in the next release.
Meanwhile, a patch is available, attached to this thread.

Closing as solved.