dns66
dns66 copied to clipboard
julian-klode
Integration with AdAway?
Hi, great work here. I help maintain AdAway which was just updated to support android 7.x and latest root methods (systemless). It does an incredible job and by the nature of its functionality virtually no battery drain etc. In fact blocking ads will help the device load pages/apps faster, etc. It's one downside is it requires root. Root is getting more difficult to obtain on more devices. Though dns66 can surely stand on its own, I'm wondering if you'd consider any integration with AdAway? This way the large user base of AdAway, if they move to a device without root, would fall back to this functionality. Basically if AdAway can get root rights it does what it does today, if it can't it'll use this method to block hosts. Same hosts files can be used etc. I feel like it'd be a great integration so users just have a one stop app that will get rid of ads or just unwanted hosts. Could even re-brand AdAway66. Let me know your thoughts, open offer.
One of the major blockers is that DNS66 really requires Android 5.0 or newer (API level >= 21). The reason for this is the use of the Os.poll() function. Os.poll() allows us to queue all reads and writes on the device and all sockets at the same time and operate in a first-come-first-served manner, and implement reasonable timeouts.
Without Os.poll(), all we could do is use threads (possibly also datagramchannel and selectors for the DNS server connections). Now with a thread pool this won't work correctly: Let's say I have 16 threads maximum: If the first 16 requests time out, all others will time out as well, because they were blocked by the previous one. If I run with an unbound thread count, I probably end up with a higher resource usage. NIO with selectors might solve the problem: We can do 2 threads for read/write device, and then use nio's selector in a third thread on all the datagram channels for communicating with DNS sockets.
the 3.x version of AdAway already is Android 4.1 or greater only. I don't mind bumping to 4.x AdAway and setting api level to >=21. Anyone on Android < 5.0 can continue to use the older AdAway's to block ads. Any new features added to date have really been to support newer android or newer root methods. So I think sticking with Os.poll() and bumping AdAway to 4.x with >= Api 21 would work.
I don't see the problem, if you want to use the VPN method of dns66 with AdAway then just do it. The code is right here.
@julian-klode Keep the applications separated, don't integrate.
I don't find it professional to just take code here just because it is open source and go ahead and integrate it into another app. I prefer to communicate with the creator/owner and have a discussion. Also, dns66 should probably live on separated, I just think it'd be great to add into AdAway for that user base getting a non-root option.
@f1vefour Hmm, we could probably share 80% of the stuff. A few things are different though:
Obviously, DNS66 is sort of supposed to be a study in best practices in Android development (not UI design, I'm horrible at that... - well, at least it looks somewhat Material-like) while AdAway just works already:
Consider updates, I'm still not entirely sure what I want to use for syncing hosts files, so many options these days: Alarm/JobScheduler/SyncAdapter - whereas AdAway uses the old Alarm system.
DNS66 also raises the bar in license compliance by actually bundling the licenses with the binaries as they require.
@0-kaladin Heh. When I took the initial core code out of AdBuster, I basically had no communication with the original author. That was not the most sensible thing to do in retrospective, and I'm not sure why it happened like that. I basically just wrote the UI code and then thought: Hey this core code looks useful, I'll translate it from Kotlin to Java and make it single-threaded to fix some bugs (AdBuster used a thread pool which obviously fails once all threads have started blocking on a DNS read - even with time outs, it would cause a cascade of timeouts on pending threads).
It makes sense in any case to provide a clearer interface between the UI and service parts: The coupling is currently a bit higher than it has to be. I think we can probably get this down to something useful, so we end up with a re-usable component that both can share.
But at this point, I personally would have no need to keep a separate project up and running anymore: All I want is basic DNS-level ad-blocking. I don't really care about any of the other enhancements.
All that said, the core code (coming from dbrodie/AdBuster) is still GPL-3-only, not GPL-3+ like AdBuster. I'm not sure if that's a concern for you, I've talked to @dbrodie about relicensing it to + properly, and he was open to that. That said, I'm in no hurry and he wanted to do a commit there, so ...
@0-kaladin Developers license their code in the manner they wish it to be used generally. I agree it's good to communicate your intentions to the persons/group that created what you intend on using but ultimately the license is good enough. I wasn't trying to step on your toes, AdAway is a great application and is used by a large amount of people considering it needs root. Implementing the non-root VPN method dns66 uses would be of tremendous advantage. The users certainly would appreciate it.
@julian-klode Creating a pretty and functional UI is hard, I'm certainly like you in this area. I put off creating this very application and had a great desire for it, thank you for doing so and sharing.
Hi @julian-klode ! Like @0-kaladin, I am the new maintainer of AdAway (for 3 years now) and I think the main drawback of AdAway is to require root. I am still interested to work with you and your project to create an unique solution which could combine own two solutions.
I can easily require the minSDK you want (and if I can have native Java 8 support in bonus, it would be great!) and I am open to adapt AdAway the way we like to make the merge work. I mean, the goal is not to take AdAway and add your stuff as a non-root fallback based on your project. The goal is to take the best of our apps and make it work together. Your hosts source selection seems better, your app filter is really nice (even if you could only work as a per-app VNP) whereas I like the blacklist/whitelist/redirect and dns request monitor from AdAway.
As said previously, even if your code is open source I would rather discuss with you than copy / paste / plug your code in my code base. AdAway has a big user community and a small developer team (me, myself and I, plus @Vankog which helps me with translations) so I think working (I do it freely as a hobby) together could be an opportunity. Let me know if you are interested and feel free to ask any question you have about AdAway!
Note: If you would like to talk in private, don't hesitate to tell me so.
