On this page
https://developers.google.com/admob/android/test-ads#add_your_test_device
it says
Note: Be sure to remove the code that sets these test devices before
you release your app.
Can anyone explain why? Why can't I leave the line of code that sends my particular device test ads no matter what? Doesn't this help prevent me from breaking AdMob's rules about developers not accidentally giving themselves false impressions or clicks?
I don't remove the testdevice directive in any of my apps. This is for my own protection - when I download my own apps from the App Store I still only want to see advertising marked as test advertising on my own devices. I have had no detrimental effects from leaving the lines of code in and most importantly it protects me from Google banning me from Admob if I inadvertently click on one of these ads. Clicking on your own non-testAd advertising that is displayed inside your own apps is particularly frowned upon by Admob. Rest assured that all other users (those not inside the testdevice directive) still see real advertising not marked as testAds.
Edit June 2019 - I still do this 2 years later. In the latest Admob API's you will see real advertising for real companies, but it will have a small "TestAd" text over the top of it. This signifies that the ad is marked as a test ad, and you won't be penalised by Admob for clicking on it. Never click on your own ads without the TestAd text!!!
The reason the docs say to remove test device in production is there is a low-risk security issue whereby if you leave that code in your app, someone could theoretically deobfuscate the APK, get your hash, and detect you as the author of the app if they put some malware into a different app that you have on your device. Removing the test device ID from the app eliminates this risk.
If you're ok to assume that risk, it's better to leave the test device ID in the app, so that you can continue to click ads from that device in production without worrying about generating invalid traffic.
There is no exact reason why that line for using test devices for ads should be removed. As a general rule when releasing apps, all traces for testing and debugging should be remove in order not to interfere with the release version of your app and in order to avoid any loop holes in your app. With that line in your code, that means if someone is using a device to test your app with the same test id, you won't get anything from admob because it is using a test device id rather than an actual device id. What I usually do is just comment it out for easy testing later on when modifying my app for another version release.
If you have the addTestDevice() in production, user wont be able to see real ads, no matter what is the device id passed to the method.
You should only use this code in testing.
Related
I had an app (a game made with Unity) on Google Play with AdMob ads enabled. I wanted to update it but I forgot my keystore password, so I decided to publish a new app with different package name but I didn't create a new app on AdMob. New app is using the same ad units and app ID with the previous one. I assume it will work since I'm using the same app ID and test ads seem working.
I have several questions;
Should I create a new app on AdMob as well?
Is it going to work?
If I publish the app this way, will my AdMob account be suspended?
Have you tried looking for a way to update the app even if you have lost your password? By contacting support or by searching on google.
Googling quickly I found this, maybe you need it: https://medium.com/#farukcankaya/recover-your-lost-android-keystore-file-633c853bd11f
However no, you have to create another app on admob, you can search online for official documentations, where they say that the package name of the admob app must have the same name as the package of the play store app. Furthermore you also need to connect the admob app to the app on the playstore correctly. So you have to recreate everything (app id, adunits, etc ...)
On this other thing, however, I'm not sure but I go by memory: I think that having two identical apps is a violation of the rules of the playstore. So if you create another identical one, I think you should take the previous one off the market.
On functioning it will never be as correct as it should be. If you don't connect it (admob-playstore) and if they don't have the same package name it might work badly or not at all.
I think creating another app on admob is the lesser evil.
I have a very big problem with Android Google Play Console.
When I put a build online, an army of robots (which I guess belong to Google) come and use my application.
The problem is that my application is an application that doesn't need an account because accounts are created automatically, so every time I put a build in internal testing, beta or production, I end up with about 50 new accounts and the robots completely destroy all my analytics.
I thought I could fix the problem by disabling the "pre-launch reports", but unfortunately, the problem persists.
How do I tell Google not to use my Application with its robots? Or is there a way to distinguish them from normal users?
Thank you
The answer is you can't. You have to treat them like normal users as this is Google verifying your app that follows their policies.
I will soon release my first Android application on the Google store. But I have one problem. It shows test ads, but when I change my ad to real one it is not showing. I am using AdMob for ads.
I read in one place that they show 1 or 2 hours AFTER I put my app on store. But if that is not true I can get myself in problems (my app functionalities are bounded to ad showing).
Please someone who has experience tell me is this true (or solve problem different way)
Test ads are always shown on the emulator. If you are using a real device and still get no real ads after a few hours, then search the logcat for "testdevice". Usually, if the AdMob library recognises an emulator or a debug build, it lets you know that it considers this as a test device. You have to use a real device and a signed release version of your app. You can also upload your app to the PlayStore Alpha or Beta channel and test it from there if you want to be 100% sure.
Admob shows real ads if following conditions are met:
See if you have added a payment method in admob console.
Your app needs to be published on play store for showing real ads.
Check your email inbox regularly. Admob asks for personal identification once in a while to resolve it you will need to add your national id card picture.
Sometimes they restrict your ads due to invalid traffic checks.
If your test ads are working it means you have implemented it correctly.
I want to submit my app to pre-launch report in Android Developer Console. The app is currently Admob enabled. I heard that the test devices will automatically crawl the app and will perform basic actions every few seconds on the app, such as typing, tapping, and swiping. I fear that this will lead to invalid click on the Admob ads.Please advice me.
Sadly got my AdMob suspended!
For future folks out there...
STAY AWAY FROM PRE-LAUNCH AND ADMOB prior to fully reading outside the Play Developer Console. (which is the one suggest in the answer above me)
I think Google should make it more clear (they know to detect many features within the APK they should at least put it clearly somewhere!).
Well.. after I got some of my own steam in this answer.
It seems the safest way at least with AdMob is a suggest here.
So there are 2 options:
Make sure pre-launch is turned ON only for test apks (without Ads). to avoid release Ad Units.
Add the following snippet to your code:
private boolean isTestDevice() {
String testLabSetting =
Settings.System.getString(getContentResolver(), "firebase.test.lab");
return "true".equals(testLabSetting);
}
Thank you for making my day Google!
https://firebase.google.com/docs/test-lab/overview#testlab_and_mobile_advertising
You should blacklist the IP range listed in the above website.
Not sure if this is the right forum and struggling to articulate this questions but here goes:
We have a process in place where we regularly release testflight app builds in order to test new functionality and fixes in our app. We always point these builds at our production environment (API’s, databases, etc). This causes us some issues like:
We are regularly trying to test stuff which has not yet been released to production (i.e. backend stuff may have not been updated yet)
When we do move code from our backend test environment to our production environment it has potentially not been tested as the app never points there.
We dont see what our real production users see as we are always on more advanced builds.
I am sure there are a number of ways we could do this a lot better but a key requirement we have going forward is to be able to release versions of our app which point to our test environment so we can correctly test things end-to-end to help alleviate the above issues. At the same time we also need versions of our app pointing at production as we use the app ourselves day to day.
The two obvious choices that I can come up with are:
Option 1 - Have separate test and production apps
By this I mean we have two apps released with two separate bundle id’s and names (like app_test and app_prod). You can then load both of these apps on your phone at the same time.
Option 2 - Same app built to either point at test or prod
This is basically where I would release the same app pointing at either production or test. You can only have one or the other on your phone at any one time.
Option 1 feels like the right thing to do but I have a number of issues with it:
The configuration of push and provisioning certificates will be more complicated
Inbound push notifications will be hard to understand and debug on phones if you have the two apps running
We would need to either submit a second app to app stores or we will need to use a third party release tool like hockeyapp or whatever.
Our semi automated build process would need reworking to support multiple bundle ids and stuff
Option 2 on the other hand presents itself with problems too:
You can only have test or production apps on a single device at any one time. This implies we would need to get more devices to test from
There is a risk of releasing an app pointing to test environments to our production users.
I guess a 3rd option would be to have the ability to reconfigure the app to use either environment (by way of a hidden dev menu or something). This concerns us in regards to caching settings but maybe that could be worked around. I guess it also means we could only run one version of the app on a device at any one time.
Anyway, this is quite an open question for advice. I am really keen to hear what other people are doing when it comes to testing apps. I have read up a bit on this and spoken to a number of people to get input (which is what leads me to the above two options) but would appreciate more input and advice. How do you solve this problem? Maybe I am just approaching this from the completely wrong angle!