yashsingh1/xdaforums huggingface dataset:
[Android Apps and Games] Mike B.:
Ads are legitimate marketing and informational tools and may generate revenue for whoever

manufactures or sells

the advertised product. However, ads displayed by a third party for the sole purpose of creating revenue for whoever merely

displays

them are a major annoyance and should be blocked whenever possible.

AdAway doesn't block anything. It merely helps the user select which hosts he/she wishes to contact. ;)

---------- Post added at 10:38 AM ---------- Previous post was at 10:16 AM ----------

XDA-Labs use the Android installer which knows/cares nothing about F-Droid. Once again, this has nothing to do with XDA-Labs or AdAway. Under Android, you may not overwrite an application (ANY application!) with one that carries the same name but a different signature, a very basic safety measure.

Please note that F-Droid never contributed a single line of code to AdAway. Anybody can compile their own version of AdAway from the publicly available source, using their own certificate, but none of those versions will be compatible, as mentioned countless times in this thread. Any AdAway version that ever appeared in the OP (or now on Labs) can be updated quickly and painlessly to the latest from either the OP or Labs. Any "alien" version, from any other source, will first need to be uninstalled as required by Android, but you can still restore your previous data after installing the correct version.

If you prefer, you can keep on using whatever is on F-Droid, keeping in mind that they neither develop nor support AdAway and that there's no guarantee that they always have the latest version. Currently, they offer one labeled "3.1.1" which is probably based on the latest 14-Apr source from GitHub (but of course incompatible with the versions from here or XDA-Labs). Pick one and stay with it, then you won't have problems... ;)
[Android Apps and Games] tag68:
I usually prefer the original. My point is not that I have some problem. As already written: I was glad that I did a screenshot of my lists. Everything is fine. But: One day later another user has the same issue.

It makes no sense that xda labs displays an update, but does not warn that the signature is different! Why shouldn't it compares the signatures, and if they are different display a warning "backup your data, uninstall, install will help if you want to install this update"? There may be some changes to XDA Labs necessary, but it should be worth it.
[Android Apps and Games] dex87xda:
Cant import Lists...

Sent from my Xperia
[Android Apps and Games] pkelly517:
Or, how about the user be responsible for his own device? Know what is installed, from which location and act accordingly?

AdAway gives you the option to export/import your lists. Use it. And AdAway should not be reminding users to backup data.

Hand holding and entitlement should not be required of the dev when writing code.

I write a good deal of code in my job. I do my best to idiot-proof the code. Fortunately, I work for a company that hires better idiots. It keeps me busy. It's my reward for standardizing the hardware.
[Android Apps and Games] tag68:
Most users have no idea. And I think it is fine. They shouldn't have to.

Exactly. That's the job of an app store/manager. Like Google app store, F-Droid or XDA Labs.

Detect wrong signatures in my opinion fits perfectly in the job of XDA Labs! Your tries to make the user responsible for the signature of the apps in some app store convinced me of the opposite ;)
[Android Apps and Games] Mike B.:
You didn't even need a screenshot of your lists if you had kept a backup, always a wise precaution for any app. After uninstalling your old version and installing the new one, you could have simply restored the AdAway data.

Let's try again. AdAway is an open source project. That means that ANYBODY can grab the source and compile his/her own (mutually incompatible) version. Since our [MENTION=3355398]mrRobinson[/MENTION] is now officially maintaining the project, it can be said that the versions available from here are the "original" ones. They are also the only ones under active development with full support. That said, nothing compels you to download from here or XDA-Labs.

The recently introduced XDA-Labs are now an alternative repository for these "official" releases. It would be completely impractical for XDA-Labs to examine every app they offer and then explore any similarly-named app on the use's device to compare certificates, then come up with a custom warning message for each app that may be based on the same source but compiled separately. Note that F-Droid doesn't do that either, and neither does any other depository I can think of. The only reason you had a minor problem is that you tried to overwrite an old incompatible version by deciding to download from XDA-Labs before you had a chance to read this thread where the matter has been discussed many times. You'll face the very same issue whenever you try to update an F-Droid download of any app with anything not coming from F-Droid or vice versa. If you prefer to get your AdAway updates from F-Droid, you may certainly do so. If you opt to get the official versions from here or Labs (a wise choice), you can do so as well. You just can't mix them up. You have to pick one or the other.... or compile your very own version using your very own signature.

For all users who have either an AdAway version from the OP (any old version from the past several years) or an earlier XDA-Labs version, the upgrades are painless and require no special action. If you still feel that somehow XDA-Labs should examine all your apps and warn you when you have a version from another source, feel free to bring it up in the XDA-Labs forums but it's probably unlikely to gain much support.
[Android Apps and Games] mrRobinson:
you have to give adaway the storage permission. This is a known issue i have with >6.0, i don't have adaway ask for it.

It may sound weird since adaway has root access we could just do it via root but since this backup/restore touches the users sdcard I'd rather do it correctly by using the correct permissions in android.
[Android Apps and Games] IronTechmonkey:
I have this same problem on my CM12.1 (December 2015) with SuperSU 2.65 where both the native android file manager and CM's file manager show a grayed out file just like in your screenshot. The workaround I use is to select an alternative file manager (which in this case is Total Commander or MiXplorer) then browse to and select the list.

View attachment 3721037
[Android Apps and Games] mrRobinson:
Just to elaborate on what Mike B said, this is outside the scope of the app store (xda labs). If I, as the developer, upload two different signed versions of AdAway then XDA Labs could throw me a warning stating as such and asking if that is what I truly intended. ( I might change signature one day, there are reasons ). But something signed by F-Droid, it has no way of knowing which is the purpose you specifically described.

Remember, F-droid is different from any other app store, and they are by design. In every other app store, amazon, google play, now xda labs, a developer does his own builds, signs his own app and uploads it to the store. Hence installing that app from any store won't give you incompatible installs.

The whole purpose of F-Droid is that apps in there are guaranteed to be open source. So THEY, not the dev, will do the build to prove they have all the source (nothing is closed) to create the app. This is a great feature for those who want to use open source software and have that level of guarantee. The only thing better is by compiling it yourself. But because f-droid is special in this way, it is signing all of its builds with its key. XDA Labs and any app store expects the dev to control his keys and change when he/she may need to.

So in short, if you installed any app from F-droid that you then want to install from somewhere else, you'd be best served to backup, uninstall, and then reinstall. Don't throw that job on any other app store when the single special case is F-Droid. Hopefully that might explain it clearer?
[Android Apps and Games] IronTechmonkey:
Looks like we cross posted. For what it is worth I see this in CM12.1 (Dec 2015)/SuperSU 2.65 where I cannot give apps storage permissions manually and where Adaway has no problem writing hosts file and seems to have write permissions to SD. (this all regardless of the storage location to which list is saved).

View attachment 3721043

Not really a problem since I would have those file-managers on the device anyhow.
[Android Apps and Games] dex87xda:
Hm strange, i set storage permissions but still cant import file..

Im using Z2, 6.0.1 super su 2.71

Sent from my Xperia
[Android Apps and Games] IronTechmonkey:
Can you import it by using a 3rd party file manager as described a few posts above? http://xdaforums.com/showpost.php?p=66397031&postcount=5862. Although that workaround is from L5.1.1/CM12.1 I'm just curious if it is also effective in Marshmallow.
[Android Apps and Games] dex87xda:
Nice :) thank u :) this method works.

Sent from my Xperia
[Android Apps and Games] tag68:
Similarly named? Isn't the Android name of the F-Droid-version identical?

Had a look in both APK packages. Compared the folders inside the apk (Download 3.1.1 F-Droid and from the OP, 7zx x for both, then KDiff3 for compare folder).

*.RSA *.SF are 2 different files.

buildserverid and fdroidserverid only exist for F-Droid

META-INF/MANIFEST.MF lines Built-By/Created-By are different, some SHA1-Digest (for different files of course)

res/raw/help_about.html additional line help/about "compiled by mrRobinson"

AndroidManifest.xml org.adaway3.1.123 6.0-2<number>uses ... the number is different

classes.dex differ (binary, no further comparison by me)

That is all.

So, the name is not similar. It is identical. Otherwise it would make no sense to warn. Right?

Remember, I did not want to suggest more than display of a hint

"The signature of that app is different, although the name is identical. If the install does not work fine and you want to switch to the new signature, please do 1. backup data of that app 2. deinstall app 3. install app"

The behavior should not be changed, only add that hint if the signature is different. The user shall be able to do the same things like before.

That's why I thought about the message: This choice is new. If you wanted to have automatic update, you did not have the choice to use the original adaway. Guess many people installed F-Droid version of adaway because there exists update management, although the original with automatic updates would have been first choice. Now that XDA Labs exist and manages updates, I'd expect more people to switch like I did.

I'll think about it and maybe I suggest it (on click update check signature and display hint if app with exact that name but different signature is installed), but not today for sure.

I wasn't aware that F-Droid - different from other app stores - always compiles again and signes separately! Thank you very much for the hint! But if the version is not incompatible, the hint will not display, and using different app stores except F-Droid will not behave different if that hint gets implemented.

Thank you for your patient explanations anyway, I see F-Droid a bit different now and got the idea behind.
[Android Apps and Games] pkelly517:
If 'most users' who install an app that has root access have 'no idea' where it was installed from, then 'most users' are at fault.

I don't think 'it is fine'. They should be responsible, or suffer the consequences.

I think my company may have a position available for you.
[Android Apps and Games] Mike B.:
There is absolutely nothing new about this situation. Different AdAway versions have been available here and on F-Droid (among other locations) for literally years, and there are many ways to get notified when a new version of an app becomes available. Attempting to overwrite an app with one of the same name bearing a different signature has been prohibited by Android for years. Now that you presumably have a copy of AdAway from here, if you try to update with a version from F-Droid, you'll get the very same issue, as expected. Frankly what you describe is a simple case of a trivial user error, or at least user oversight, easily remedied, and one over which AdAway has absolutely no control.
[Android Apps and Games] Makxie:
oh wow sweet news. I've been really using this one thanks a lot :good: I even use it on my android tv box
[Android Apps and Games] moovit_developer:
Adaway interfering with a specific https request

Hello,

We have an app that uses https with certificate from Comodo and the url is *.moovitapp.com

We have received several reports from users that claimed that using AdAway has prevented them from accessing our app's content.

Is there any reason for this to happen? (obviously we are not an ad agency or analytics provider, we're a transportation app)

Is there a way to verify that this is the case with the block reason in any log that the app outputs?

Thanks,

Moovit
[Android Apps and Games] Mike B.:
Welcome to XDA!

AdAway merely helps the user edit his/her /system/etc/hosts file. It can't prevent anything from accessing any app's contents, and it 's only active when specifically invoked to (optionally) update that hosts file once in a while. The culprit can't be AdAway but it's very possible that your users are blocking a host (in their hosts file) that your app requires, whether they did so with help from AdAway or not.

I would first suggest that your users refrain from loading any of those "ad-blocking" monster source files that create a huge hosts file and try to block way too many hosts for no good reason. AdAway suggests a few public source files that are more than sufficient for most people to block commonly encountered ads. Nothing in those source files makes any reference to "moovitapp".

If your app is still "blocked" (again, whether AdAway was used to edit the hosts file or not), the users should verify that they are not inadvertently blocking a host that your app requires. There is a convenient DNS Request Log tool available from AdAway but surely YOU know which hosts you need (not just "moovitapp.com") and your users can readily see if any of those hosts are blocked or redirected in their hosts file. The AdAway documentation explains how a user can easily enable a little tcpdump service, run your app, then review the resulting DNS Request Log to see which hosts it called and either blacklist or whitelist those hosts as required.

That said, I found something called "Transit Directions by Moovit" on the Play Store which I assume is the app in question. I downloaded and installed the app on a device running the current AdAway with only the default suggested source files enabled, and had no trouble at all accessing your contents (using a few random locations). This leads me to believe that your users are simply guilty of the common sin of trying to block too much and are loading some of those overly aggressive source files that cause more headaches for no benefit. The solution is to not do that! ;)

They'd face the same issue if they edited their hosts file manually without AdAway. If all else fails, tell them to read this thread! ;)
[Android Apps and Games] chinouii:
Your explanation is kind of understandable :). Got it wrong
[Android Apps and Games] mrRobinson:
Just to add to what Mike B. explained, the AdAway app itself doesn't own the lists that are blocked. So even if AdAway was blocking moovitapp.com, you'd instead want to find what source list that was blocked in and go to their forums to discuss getting it removed. AdAway has no control over the source lists except for one.
[Android Apps and Games] R37ribution:
I tried flashing AdAway_systemless_hosts_v2.zip with twrp 3.0.2-0 and I get zip signature failed. I've tried downloading the zip twice and compared the md5 sum to the one on androidfilehost.com as well as the shasum to the OP - both matched.

Anyone else experience this?

I read that there are different sources like Fdroid that have different signatures. Is TWRP comparing signatures from F-droid or something?

Thanks.
[Android Apps and Games] Mike B.:
The "systemless" ZIP is actually unrelated to AdAway. It merely executes "mount -o bind /su/etc/hosts /system/etc/hosts;" on boot so that applications (including AdAway) can access /system/etc/hosts as if they had full access to the /system partition. This has nothing to do with F-Droid or app signatures.

What you experience is probably a TWRP 3.x glitch. The easiest approach would be to (temporarily?) disable the "zip file signature verification" option in TWRP before flashing the ZIP.
[Android Apps and Games] osm0sis:
More likely the zip just isn't signed. Same solution though. :)
[Android Apps and Games] Mike B.:
I'm not familiar enough with TWRP's requirements, but if the message was "verification failed" without a prior "signature not found", it sounds like a nice way to confuse the users! ;)
[Android Apps and Games] osm0sis:
Yeah it would definitely be more user friendly if it would differentiate between failed signature and signature not found when people have zip verification enabled, but I don't think that's the case currently. [MENTION=4878287]_that[/MENTION] ? ;):)
[Android Apps and Games] cleverdicky:
Hi, im not clever enough to fully understand all of how this works. Im just gratefull it does, thanks.

But ive a question i dont believe has been asked before. Cant find anything like it.

So It may not be relavent or possible. But is there a method or setting i can use easily that blocks ads for aps now appearing on a lot of (mobile) web pages.

Pretty sure its java based but even though i have browser set to view pages as decktop, they somehow know. After opening a page, and what seems an age of white space, half the page is taken up either overlaid or pushed down with a big ad asking if i want to download their app.

I dont ! And neither do i want to see a big ad asking me until i have to close it and refresh the page.
[Android Apps and Games] Mike B.:
It's a bit difficult to understand your question, but it seems you haven’t had a chance to read what AdAway is and what it does. It actually has nothing to do with ads, browsers, or Java. When you try to access a host ("google.com", for example) from either a web page or an app, your system needs to find that host's Internet address (IP) and to do that it uses a process called Domaine Name Service (DNS). The first DNS step if to look in a local file (/system/etc/hosts) where names are paired with addresses. An entry in that file can contain either the true address of the host, or instead use a "fake" address that leads nowhere, effectively blocking that host. AdAway is a tool that makes it easier to edit that file without having to use terminal commands or a separate editor.

Coming back to your specific concern, if you know the name of the host that displays the ad you don't want to see, you can "block" that host. The default source files suggested by AdAway manage to block most but not all commonly used ad hosts. See the AdAway documentation on how to block more hosts or even add entire new source files if you must. Note that unless the host in question is called by name, the app/page will directly access it and the DNS process won't apply, meaning that you can't block it from the hosts file, with or without AdAway.

Finally, if you successfully block a host, i.e. you don't see its ads, but you now get a "not found" message or still see an empty space where the ad would be, simply enable the AdAway webserver which will fool the app/page into thinking that it has received valid data.

Since you didn't give any specific example of which page or app you had in mind, we can't get too specific but it seems that you would greatly benefit from searching this thread and/or reading the AdAway documentation or wiki. ;)
[Android Apps and Games] cleverdicky:
thanks. i do no it looks up the hosts file.

And i did search...!

Here is an example. You have to be using a mobile to see it appear.

http://www.lidl.co.uk/en/index.htm
[Android Apps and Games] Mike B.:
What specific problem do you have with that page under which browser? Accessed from Chrome or Firefox (with only the default AdAway sources and settings), yes, it's full of ads, but that's expected since it's apparently a site all about "offers" (basically just a bunch of ads). One of the countless embedded ads offers to download their mobile app, but it only takes a very small space and can be dismissed with a simple click. As far as I can tell from a cursory look, that ad is no different from all of the others there and comes from the same hosts. Are you trying to disable only that specific ad or all ads? If you don't like their web pages, any reason why you prefer using a browser instead of their (free) Play Store app?
[Android Apps and Games] mchlbenner:
Not an ad blocker it is currency app spam!!
[Android Apps and Games] Suarezian:
Adaway is not blocking ads for me anymore, not in the apps and also not in browsers. I opened adaway and installed it. And after reboot, when I open adaway again, it says disabled. What should be done?
[Android Apps and Games] Mike B.:
It would help if you gave us at least some details, such as which device/ROM/version/root you are using, and most importantly what you changed on your system between the time AdAway was working and the time it apparently quit working for you.

When an installation fails to survive a reboot, it often means that you don't have a full root or that your configuration prevents writing to /system, issues not specific to AdAway but that can often be easily remedied such as by creating a symlink. Please search this thread for any keywords relevant to your situation and if you can't find your answers here or in the AdAway documentation, give us enough information so that we can at least point you in the right direction.
[Android Apps and Games] cleverdicky:
Stock browser s4.

I no its all ads. its just an example. My question was can we block / filter etc the AD for Their App.

They are usually at the top of each page untill you hit their 'x' to close it.

Most annoying.
[Android Apps and Games] Mike B.:
Apparently you haven't had time yet to review what AdAway is and does. The DNS process and the hosts file only deal with

hosts

, not specific pages, images, or HTML elements. You could use the AdAway DNS Request Log (see the documentation) to determine where a particular ad is served from, but even if you're successful you could only block that entire host, not just one ad from that host.

Note that on my phone, using Firefox 45.0.2, I only saw the "use our app" section once and never again after I dismissed it, but it might be only triggered by specific browsers, user-agents, or even locations "Stock browser s4" doesn't tell us much since there are many different android and carrier firmware versions for various S4 models using different browsers, but try another browser (making sure cookies are enabled) if that ad bothers you. As suggested earlier, using their mobile app directly would seem to be a valid alternative but since it's not supported in my country, I can't comment on it. For further information, you may want to contact the Lidl people directly.
[Android Apps and Games] Suarezian:
My device is One plus one, and I tried two different ROMs: Dirty Unicorns and CM13. Using the latest Super SU. Root access is there. The hosts files are downloaded and applied successfully, but after a reboot, if you open adaway, it says adaway disabled.

Sent from Steven Gerrard's boot!
[Android Apps and Games] Mike B.:
Have you checked (from a Terminal prompt, for example) whether your /system/etc/hosts file contains the expected entries after a reboot? Could it be that you're using a "systemless" partial root, (a SuperSU feature/limitation) which denies access to /system. If so, have you tried first flashing the "AdAway_systemless_hosts_v2.zip" from the OP which would allow apps (including AdAway) to indirectly edit /system/etc/hosts? Re-read the OP or

search this thread

for details.