It’s very hard mission! I replied to email and also contacted to pеrson from Admob with whom spoke once.
Appayable Representative here:
It has come to our attention that a large number of Android Developers have received notices over the past 24 hours from Google. These warnings refer to section 4.3 of the Developer Distribution Agreement. Thank you for sharing the specifics of each of your cases with us in this forum - it is much appreciated and will help us as we explore the situation internally, with our partners, and Google.
While a number of developers whom have received this notice are part of our community, similar notices have been delivered over the past day to developers without the Appayable SDK.
We are investigating this matter and speaking with Google to clarify if the issue resides with our SDK.
I will personally keep in touch with all forum members via email or on this forum throughout this process and will provide an update as soon as I have more clarity on the situation.
In the interim, we recommend you reread Appayable Terms of Use which require disclosure of the collection of data and implementation of Appayable within your own application’s Privacy Policy/EULA.
If you have any questions please contact me directly via email (keith [at] appayable). We will update you in the near future.
Best,
Keith
If the app had Appayable in the past, but not now anymore, it means that the users who didn’t make the app update may continue to send Appayable data.
So, are we “screwed”?
Yannis, I am trying to reply to your email, but receiving “Mail Delivery Subsystem” failure. Do you have a different email which I can use to message you?
~KP
KP, my worry right now is :
I don’t have any EULA (yet).
Would it be OK for the Google policy if I only publish an update of my apps without the Appayable lib??
I do not want to speak to Google Policy specific to your application, but I would normally assume that removing the lib would result in an approval. However, as you can see from previous posts on this Forum today, there are a number of applications which are still receiving notices from Google even without Appayable’s lib and/or query in the app.
KP
You are right. Edealya library present in apk.
Ok, Thank you for your answer
So what is the proper way to submit the modifications. We just upload a new app version? do we have to somehow contact Google play support
about it?
Now the most worrying part is that people receive the warning whether there are current or past violators. If I remember correct the Pingjam case
developers got banned even though they removed the sdk. Please post here if you receive any reply from Google.
There is a community of developers using andromo developer tool that also got these warnings. Seems that andromo was including appayable sdk
without their knowledge in the APK. You can follow their thread here: violation of google play - Andromo App Maker for Android Forums
Hi guys. I think that the problem is in Appayable SDK. It seems that google bots scanning APK files for this Appayable SDK. Warning messages to people who used Appayable in the past or never used Appayable in the specific APK (but used in others projects) could be explained by the following assumption :
before ADT 21, it compiled the external libraries into dex code every time you hit the “Run” button in eclipse. Now it will compile the dex code for the external libraries only once (until they change) and use the prebuild libraries for later "Run"s.
developer tools - dexedLibs folder in android project - Stack Overflow
android - What’s the difference between dexedLibs and libs? - Stack Overflow
As for me I have 25 warning messages from Google. Only 8 apps have Appayable SDK at that moment (in the libs folder). Another 17 apps NEVER have Appayable sdk in the code of the project, but they have Appayable jar file in the bin/dexedLib folder, as I have used this jar in my project that have been marked as library project in Eclipse. So all these 17 apps have my library project that have Appayable lib respectively.
The only solution is to find all Appayable.jar files in your workspace. And then delete them:
Also you should CLEAN ALL projects in workspace and then rebuild app and updated them in the market. I couldn’t investigate another solution.
I came to the same conclusion. In my case: In part of apps I found Appayable, in other Mobilecore.
So my suggestion to remove both and before publishing check apk again for what he includes.
Good news guys , it is 100% Appayable. I have reverse engineering my old APK files and figure out the all my 25 apps have Appayable sdk inside.
You also can decomplile your apk with APKTOOL :
Downloads - android-apktool - A tool for reverse engineering Android apk files - Google Project Hosting
[UTIL][Feb 02 2013] Apktool v1.5.2 - a tool for reverse engineering apk files - xda-developers
[GUIDE][HOW-TO] Decompile and Compile apps using Apktool in 5 Simple Steps - xda-developers
if you find inside your decompile file such folders:
smali/org/OpenUDID
smali/com/a/a
smali/com/edealya/lib
So the solution is:
rebuild you app without this Appayable library
Thanks for the update!
Although I’m also pretty sure it has something to do with Appayable, I’ve checked the apk of one of the apps that I got a warning for - and there’s nothing of that sort.
In the past, this app has Appayable’s SDK integrated, but I removed it a few months ago. The only trace I can find for Appayable now is in the dexedLibs folder, but I can’t find any trace of it in the apk itself, so it seems that the files in the dexedLibs don’t find their way into the apk. Which raises the question (again), what in the apk triggers Google’s bot?
I’ve cleared the dexedLibs, removed an unnecessary permission, added a privacy policy in the Play Store listing and a privacy policy message that the user has to accept upon first application start. I really hope that all this will suffice, but without knowing for sure what is that thing that triggered their bots in the first place - I can’t be relaxed until a week or two passes.
Please continue to share any findings or correspondence with Google.
Hello everyone,
I follow the discussion on Andromo forums and I got this:
OK folks, some good news (finally). Mark worked his butt off to reach out to Google Play and we heard back from them this afternoon. The prognosis is positive - BUT, you need to update your apps in Google Play immediately!
We can confirm that many apps utilizing the Appayable
SDK were notified of their non-compliance with Google Play policy. The
technical analysis of apps messaged to this effect reflected an active
non-compliant implementation, therefore were sent the warning. If the
apps are detected to be in a non-compliant state via subsequent checks
after the warning period expires, we reserve the right to enforce the
policies. If these properties are only controlled by the developer
updating an SDK or Appayable component and re-publishing,
we recommend that you message any publishers of the non-compliant
version of your framework to update as soon as possible to avoid
enforcement
We appreciate the spirit of your reaching out and will be in contact.
Regards,
The Google Play Team
So, what you need to do right now:
-
Rebuild your app right now using the most recent release of Andromo (v3.2.8/248 or higher). You can check the version from the About dialog. This version is the most current and up-to-date release that complies in every way that we are aware of with Google Play policies and has absolutely no trace of Appayable.
-
Make sure there is nothing else in your app that violates Google’s terms. Go review them to make sure.
-
Upload this new version of your app to Google Play. Make sure you upload the correct file – it must be built with v3.2.8/248 or higher.
Source: violation of google play - Andromo App Maker for Android Forums
Try to look again into decompiled apk. Because smali/org/OpenUDID and smali/com/edealya/lib will be only in last versions of Appayable lib. First versions Appayable v.1.1 have only smali/com/a/a folder and 4 files in it and also have smali/com/google/a with 4 subfolders in it. Please try to decompile your apk once again. I really doubt that google bot scans old versions. Only reason may be that you have two active apk of one app for different devices.
It could be the case that there are more than one active APKs
I switched in the advanced mode in my developer console and I see
the following warning
“Previously active APKs supported more devices than those in the draft configuration. Some devices will not receive upgrades.
Devices currently running version 11 are no longer supported by the current configuration. Such devices will not receive upgrades”
So maybe it would be a good idea to update applications using the lowest amount of features necessary to cover all previous versions.
Even though it does not seem that I have added/removed features after I used the GET_ACCOUNTS permission
Google bots doesn’t scan for GET_ACCOUNTS they scan for Appayable library in your APK.
I am just saying that maybe there is additional active apk for some devices containing the appayable sdk
even though we remove all traces from current apk version. Does google scan old versions considered active
because some devices cannot upgrade to new versions
Just in case, you’re right, I also had this message (advanced mode in my developer console), and just updated a new version only to cover all previous devices. 
I already published two apks yesterday, one for API level 7+ (as all previous versions) and one for API level 11+, to get the ‘designed for tablets’ mark, so I can’t check if I had more than one apk enabled… I used simple mode until yesterday, and now I have only the two new versions as published, all previous versions are unpublished.
I did a few things that I hope will suffice:
- added a privacy policy in the play store listing.
- added a privacy policy when running the app for the first time (even though I don’t have any sdk that collects anything personal, just admob and google analytics).
- cleared the dexedLibs folder and cleaned the entire project.
- removed unnecessary permissions (although I never had GET_ACCOUNTS for this app, but I did have READ_PHONE_STATE which I now removed).
In addition, I added some sort of a mechanism to enable me to address my users remotely and ask them to download a new version with a different package name, just in case I’ll get my app suspended anyway. I really hope to never use this option…
|