1

Every so often, after some local testing, I build and sign a version of my Android app for the Play Store that has the LOCAL_SERVER flag still set to true. Of course this causes the app to fail for people because, in general, my users can't reach a my 192.168.1.x server.

Is there any way to get the release process to somehow auto-detect that I've left that constant in the "testing" state and fail before it gets accepted by Google Play?

  • I thought maybe I could conditionally call a dummy class and have ProGuard (which only runs on a "release" build) force-strip that class which would then generate an error because it found a call to a class that wasn't present. But ProGuard has no option to force-strip a class.

  • I thought maybe I could force "android:debuggable=true" which would then cause the upload to Play Store to fail. But I can't find any way to set that AndroidManifest flag based on a Java constant.

Any other ideas? I'm using Eclipse for development.

Brian White
  • 8,332
  • 2
  • 43
  • 67
  • 1
    Maybe use the generated [`BuildConfig.DEBUG`](http://stackoverflow.com/questions/9855834/when-does-adt-set-buildconfig-debug-to-false) flag. It's only `false` in case you build a release version. – zapl Jan 16 '14 at 07:57

2 Answers2

1

  1. A release checklist.

  2. Test the signed version before releasing it.

  3. A JUnit test that checks the field's value (you still need to remember to run it though).

eski
  • 7,917
  • 1
  • 23
  • 34
  • (1) I want to *automate* as much of the checklist as possible. (2) Testing it locally still works because it's on the local network. (3) Unit test of the constant would then fail during development which would be bad. – Brian White Jan 15 '14 at 04:49
  • how about keeping the flag as a boolean resource in xml? then you could reference it with: android:debuggable="@bool/local_server – eski Jan 15 '14 at 05:24
  • That would make it a runtime check and eliminate the possibility of static analysis by ProGuard and the like. I've considered making the users of LOCAL_SERVER *and* that value with a run-time fetch of the android:debuggable flag to still do the Right Thing(tm) in the case of such an error, but that too breaks static analysis in the error case. It may also confuse tests. – Brian White Jan 16 '14 at 01:40
  • Okay, just modify the apk signing portion of the ADT plugin for eclipse to check the boolean. Check this for getting the source: http://stackoverflow.com/questions/3487398/where-can-i-find-the-source-code-for-the-android-development-tools-adt-plugin – eski Jan 16 '14 at 02:53
  • I eventually went with #3. The test is only in the test "app" that I run on a real device so the majority of the unit-testing done on the host machine isn't affected. – Brian White Apr 10 '15 at 22:14
1

Even better, stop LOCAL_SERVER being set.

class MyClass
{
    final private boolean USE_LOCAL_SERVER = true;
    void myMethod()
    {
       LOCAL_SERVER = (MyClass.class.getName().equals("mypackagename.MyClass")) ? USE_LOCAL_SERVER : false;
    }
}

Since proguard will obfuscate the name of MyClass, LOCAL_SERVER will always be false when proguard has been run.

Steve Waring
  • 2,882
  • 2
  • 32
  • 37