To give some background on the app, I began working on the app as a solo developer at the beginning of 2012, and have been working on it ever since. The app has gone through three major redesigns, first to the Holo design theme back around 2013, and again to the modern Material design at the beginning of 2016.

When I started working on the app back in 2012, I was looking for a voice recorder that could capture my grandmother’s stories for posterity, and the apps available at the time all left something to be desired. I saw that there was a place for a voice recorder with a focus on quality and ease of use. I strived to create an app where the tension between simplicity and power would be balanced, where anyone could just install and get going in seconds, while keeping the customizability that power users demand. That is still my goal today.

While I have always developed the app as an independent developer, I have definitely not been alone on this journey. I have much gratitude to everyone who has been part of the journey with me, including my talented UI designer, a great QA and customer support team, and also the many users who have pitched in with feedback and translations, not to mention my own family for being supportive from the beginning. I am also very honoured and grateful to Google for validating my efforts, and for building a platform giving small developers like myself the opportunity to work for ourselves and reach a worldwide audience.

Easy Voice Recorder can be downloaded directly from Google Play by clicking on the badge below:

Any questions or comments? Please don’t hesitate to let me know! I can be reached directly via Help – Contact Us inside the app, and I’m always happy to hear from you.

Copyright © 2012
This feed is for personal, non-commercial use only.
The use of this feed on other websites breaches copyright. If this content is not in your news reader, it makes the page you are viewing an infringement of the copyright. (Digital Fingerprint:
57093891627bcf5753cb6dde17dba8f4)

I’ve also recently noticed that Easy Voice Recorder has been mentioned in the following reviews — thanks!

Easy Voice Recorder app review
The 5 best voice recording apps for Android smartphones and tablets
[App Review] Review Of Easy Voice Recorder Pro: The Ultimate Recorder

Copyright © 2012
This feed is for personal, non-commercial use only.
The use of this feed on other websites breaches copyright. If this content is not in your news reader, it makes the page you are viewing an infringement of the copyright. (Digital Fingerprint:
57093891627bcf5753cb6dde17dba8f4)

Copyright © 2012
This feed is for personal, non-commercial use only.
The use of this feed on other websites breaches copyright. If this content is not in your news reader, it makes the page you are viewing an infringement of the copyright. (Digital Fingerprint:
57093891627bcf5753cb6dde17dba8f4)

Easy Voice Recorder has also been featured by Les Applications Android and mobile ASCII:

• Les 30 meilleures applications Android de 2012
• シンプルなボイスレコーダーで 会議の議事録を録音！

Copyright © 2012
This feed is for personal, non-commercial use only.
The use of this feed on other websites breaches copyright. If this content is not in your news reader, it makes the page you are viewing an infringement of the copyright. (Digital Fingerprint:
57093891627bcf5753cb6dde17dba8f4)

Here are a couple of ways that you can stay subscribed:

1. Head over to http://feeds.feedburner.com/Digipom, and choose one of the options in the box that says “Subscribe Now!”
2. Subscribe via email by selecting Get Digipom delivered by email.

We hope that you continue your subscription with us, and thank you for your continued support, as always.

Copyright © 2012
This feed is for personal, non-commercial use only.
The use of this feed on other websites breaches copyright. If this content is not in your news reader, it makes the page you are viewing an infringement of the copyright. (Digital Fingerprint:
57093891627bcf5753cb6dde17dba8f4)

The first strategy: using Git branching

We have used Git branches to help manage this in the past. With Git, you can easily and quickly create subbranches, so to separate by free and paid, for example, you can have a “free” branch and a “paid” branch, and then you can further subdivide these by market.

While Git is great at easily configuring a build for a different market, it can become difficult to keep track of all of the changes and to merge changes from one branch to another. Here are some of the issues that we’ve come across:

• Changing the package name means that all of your references to the R class need to be updated (I believe this can be worked around by calling aapt with –rename-manifest-package if you build with Ant or Maven, but unfortunately the Android Developer Tools (ADT) don’t support this workaround at the moment).
• Anything could possibly be changed between different branches, and it can be difficult to quickly get a “big picture” on the actual differences in configuration between branches.
• Propagating changes and dealing with merge conflicts can become a time-consuming chore.

The second strategy: using Android library projects

Instead of using Git branches, this can also be done by using Android’s library projects. The way this works is that most of the application goes into a core library project, and then there are separate projects for each configuration. This can follow the Git branching model, with a base library project for “free” and for “pro”, and different application projects for each market.

With this model, it becomes very easy to make changes to the core and have these changes reflected in each application project, as well as easily see what each configuration contains. The trick to getting this to work well is to use the new manifestmerger.enabled property; by adding manifestmerger.enabled=true to each project in the project.properties, the ADT will automatically merge most attributes from a parent project down into a child project.

There are some drawbacks to this model:

• Not all attributes get copied, so there’s still some copy/pasting of attributes between manifests.
• The build takes longer, and sometimes the build inexplicably fails. This can sometimes be fixed by closing and re-opening the project, or cleaning the projects and building again.
• If you have more than one layer of projects, then automatic running & debugging may no longer work.

In addition, because the customization with library projects is less ad-hoc than when using Git branches, we had to make the following changes to our code:

• We used polymorphism and factory methods instead of if statements or directly changing the code between branches; this required quite a few changes to structure things to make this possible, but the code is better for it.
• The R class constants are no longer final, so switches were replaced with if-else statements.

Proguard seems to work fine with several layers of library projects. We had issues with the “new” style of using proguard-project.txt, so we reverted to our old Proguard setup for each project.

All in all, library projects have some drawbacks, but they can also be a clean approach to build and market customization, and they should continue to improve over time.

Copyright © 2012
This feed is for personal, non-commercial use only.
The use of this feed on other websites breaches copyright. If this content is not in your news reader, it makes the page you are viewing an infringement of the copyright. (Digital Fingerprint:
57093891627bcf5753cb6dde17dba8f4)

Copyright © 2012
This feed is for personal, non-commercial use only.
The use of this feed on other websites breaches copyright. If this content is not in your news reader, it makes the page you are viewing an infringement of the copyright. (Digital Fingerprint:
57093891627bcf5753cb6dde17dba8f4)

Copyright © 2012
This feed is for personal, non-commercial use only.
The use of this feed on other websites breaches copyright. If this content is not in your news reader, it makes the page you are viewing an infringement of the copyright. (Digital Fingerprint:
57093891627bcf5753cb6dde17dba8f4)

• Implements a lexer, parser, and Dijkstra’s shunting yard algorithm to convert an expression into postfix form.
• Implements a simple stack machine for parsing these expressions. When using float and double, the speed is quite fast.
• Implements a basic UI, as seen below (keep in mind that many of the features are not implemented):

If you’re interested in learning more about lexing and parsing, or even if you’re just curious, you can access the GitHub project here. The code is licensed under the Apache 2.0 license.

Copyright © 2012
This feed is for personal, non-commercial use only.
The use of this feed on other websites breaches copyright. If this content is not in your news reader, it makes the page you are viewing an infringement of the copyright. (Digital Fingerprint:
57093891627bcf5753cb6dde17dba8f4)

Here’s a quick excerpt from the review:

A baby’s first words, a memo to yourself or recording an important interview – all things for which you’ll need a voice recorder.

Just because the app is free doesn’t mean it doesn’t have some impressive settings. You can select from AMR, AAC or PCM recording modes… There are also options for troubleshooting. For example, with the default settings meant that when the phone went to sleep, the recording stopped. You can fix this here, so make sure you try these settings before heading out for that interview of a lifetime!

You can read the entire review at the following link: APP OF THE DAY: Easy Voice Recorder Free (Android).

Thanks to Ian Morris and the team at Pocket Lint for a well thought-out review!

Copyright © 2012
This feed is for personal, non-commercial use only.
The use of this feed on other websites breaches copyright. If this content is not in your news reader, it makes the page you are viewing an infringement of the copyright. (Digital Fingerprint:
57093891627bcf5753cb6dde17dba8f4)

Here is a quick teaser:

Easy Voice Recorder is a holo-themed voice recording tool that couldn’t be easier to use, but hides some serious features just under the hood. If all you want to do is record a quick interview or conversation, […] Easy Voice Recorder makes it simple.

You can read the rest of the review here: Easy Voice Recorder for Android Makes Recording Lectures or Interviews Dead Simple.

I want to express my thanks and gratitude to Alan Henry and the team at Lifehacker for writing up the review, and to everyone who kindly tweeted and helped to spread the news. Thanks, guys!

Copyright © 2012
This feed is for personal, non-commercial use only.
The use of this feed on other websites breaches copyright. If this content is not in your news reader, it makes the page you are viewing an infringement of the copyright. (Digital Fingerprint:
57093891627bcf5753cb6dde17dba8f4)

Original, in German:

Meine Meinung: Der Easy Voice Recorder Pro ist angenehm zu bedienen, macht tadellose Aufnahmen, und liefert ein paar nützliche Funktionen. Für meine Anforderungen (digitales Diktiergerät für Unterwegs, Live-Aufnahme für Podcasts) einwandfrei geeignet und die Investition wert.

Translation to English, by Google Translate:

My Opinion: The Easy Voice Recorder Pro is pleasant to use, makes perfect recordings, and provides some useful functions. For my needs (digital voice recorder on the go, live recording for podcasts) perfectly appropriate and worth the investment.

You can read more at the following link (in German): Im Lounge-Test: Easy Voice Recorder Pro – das Smartphone als digitales Diktiergerät

Thanks again to Helmut Hackl and the team at the Android Lounge for taking the time to review Easy Voice Recorder Pro!

Copyright © 2012
This feed is for personal, non-commercial use only.
The use of this feed on other websites breaches copyright. If this content is not in your news reader, it makes the page you are viewing an infringement of the copyright. (Digital Fingerprint:
57093891627bcf5753cb6dde17dba8f4)

The purpose of BuildConfig.DEBUG

This new flag is intended to be used as a check for debug-only functions. For example, you can use it to control logging, like below:

if (BuildConfig.DEBUG) {
    Log.v(TAG, "onCreate()");
}

You might also use it to control other features, such as whether to enable internal verifications, add test devices for your ads or only show real ads, etc….

The idea behind this flag is that when you are debugging with Eclipse, the flag will be set to true, and when you export a signed release build, the flag will be set to false, thus turning off and on debug features automatically, without you having to remember to toggle a flag.

This would be nice if it actually worked reliably!

The problem with BuildConfig.DEBUG

The problem is that it can be quite dangerous to rely on BuildConfig.DEBUG and ADT to do the right thing, because there are bugs in the build system that cause exported signed release builds to be built with BuildConfig.DEBUG set to true!

Imagine building a release and thinking that your logs and other debug features are turned off, and later realizing that the flag was never set to false.

The solution

Although there are workarounds and supposed fixes, I don’t want to have to worry about whether or not it actually worked, and whether all of the debug code actually did get stripped out or not.  Instead, I define my own constant, such as follows:

public class AppConfig {
    public static final boolean DEBUG = false;
}

I’ll use this flag like this:

if (AppConfig.DEBUG) {
    Log.v(TAG, "onCreate()");
}

In conjunction with ProGuard, this works to remove the debug code from the release build 100% of the time. I keep the flag commited to the source tree as false, and override it to true if I need to debug.

This might be a bit of extra work, but I have peace of mind knowing that it will work every single time.

Further reading

• BuildConfig.DEBUG is “true” for exported application package
• When does ADT set BuildConfig.DEBUG to false?

Copyright © 2012
This feed is for personal, non-commercial use only.
The use of this feed on other websites breaches copyright. If this content is not in your news reader, it makes the page you are viewing an infringement of the copyright. (Digital Fingerprint:
57093891627bcf5753cb6dde17dba8f4)

We greatly appreciate the support, and let us know how we can continue to make your recording experience even better in the future!

Download links:

Easy Voice Recorder

Easy Voice Recorder Pro

Copyright © 2012
This feed is for personal, non-commercial use only.
The use of this feed on other websites breaches copyright. If this content is not in your news reader, it makes the page you are viewing an infringement of the copyright. (Digital Fingerprint:
57093891627bcf5753cb6dde17dba8f4)

Some of you might remember the old copy protection measure that Google used to have. You can still find it on your publisher page, with the following warning in red: “The copy protection feature will be deprecated soon….” Enter Android’s License Verification Library (LVL): a new tool to save the day!

Android’s License Verification Library (LVL): A false sense of security

How does the license verification library work? It manages a connection between your app and the Android Market (now Google Play), and performs a license check with the server to see if the user has a valid license for your app (i.e. it was purchased legitimately through the market). In other words, it’s a form of Digital Rights Management (DRM).

Unfortunately, the license verification library is also a joke to crack and bypass.

It literally takes a pirate no more than a few seconds to run a tool that will decompile your application, detect your licensing code, patch it to bypass all of the checks, repackage everything into a new APK and resign it. This tool is called AntiLVL. By the way, it can also bypass much of Proguard’s obfuscation, and even techniques using reflection.

For obvious reasons, I won’t link to it here, but you can find it if you do a bit of searching. This is also just one tool that’s freely available to download; who knows what other tools are hidden from public release.

What does Google recommend?

Unfortunately, you have to do a lot of digging to find out what you should do, and just how vulnerable you are. Google doesn’t offer much in the way of help and advice directly from their website, except for “well, you should probably not use it as-is and obfuscate the code somewhat.” They also give advice like “In most cases, you should add the license check to your application’s main Activity, in the onCreate() method,” which directly contradicts the advice given by Google engineers in the talk, “Evading Pirates and Stopping Vampires using License Verification Library, In-App Billing, and App Engine,” where they recommend that you don’t add the checks to non-obfuscated methods such as onCreate().

I highly recommend you view the presentation or watch the video. I would not necessarily use them directly as-is, but you can take the ideas and go with variants.

What are the weakest points?

Here are some of the checks that are removed very quickly and easily by tools such as AntiLVL:

Non-obfuscated code

A trivial check will easily take care of methods with names such as checkLicense().

Unmodified code

The default signatures of some methods are very easy to trap. For example, ServerManagedPolicy.allowAccess() has a call to System.currentTimeMillis() at the top of the method body. AntiLVL finds this code, and replaces it with a force return true.

Another bit of easily-hacked code is the enum Policy.LicenseResponse. This enum contains three constants, “LICENSED”, “NOT_LICENSED”, and “RETRY”. Even with Proguard obfuscation enabled, these constants get embedded into your code as strings, containing the same value as the enum! AntiLVL replaces the “NOT_LICENSED” string with “LICENSED”, which causes other checks to pass.

Package checks

AntiLVL can check if you’re trying to validate that your classes or signature have been modified and intercept those validation calls, even if you’re using reflection.

And much more…

There is a lot more that AntiLVL can detect and modify; you can download it and look at the XML files inside the jar to see what else it can detect. There’s also a sample project with all of the usual tricks, which are easily detected and cracked by AntiLVL.

What can I do?

The minimum you can do is download AntiLVL, run it in a virtual machine with no connection to the Internet if you don’t trust the code, and test it against your APK until it can no longer crack it automatically.

Here are some ideas:

• Wrap all logging calls in a static boolean, set to false when you build the release version of your app.
• Encode all hard-coded strings using a two-way encoder/decoder function, such as a Caesarian Shift. Change all string constants and hard-encode the encoded value into your Java source file. Decode before using.
• If you only need to test equality, use a hash such as SHA1, and compare the hashed values.
• Don’t do: public static final String SOME_STRING = SHA1.encode(“Unhashed Value”);
• Do: public static final String SOME_STRING = “5dad4014ec894587f83626ee31a8dd418d1371f1”;
• It’s better if you use a combination of techniques, since the pirates can easily search for the known hashes to figure out which bit of code is which.
• Remove ILicensingService from your ProGuard config with this one change:
   
  Change:

  boolean bindResult = mContext.bindService(
  new Intent(ILicensingService.class.getName())

  To:

  boolean bindResult = mContext.bindService(
  new Intent(“com.android.vending.licensing.ILicensingService”)

  That string can also be encoded in the source and decoded using the techniques described above, to make it a bit less obvious.

• Move your functions around, inline some stuff, change switch statements to if statements, move statements around, and reverse the roles of some methods.
• Increase your Proguard obfuscation:
   
  -repackageclasses
  -allowaccessmodification

Of course, none of this will help if the pirate finds where the license check code is being called in your app. He can cut out this weakest link, and not worry about the rest. All of these measures will only slow down the pirates, but they won’t stop them.

Is it worth it?

You have to acknowledge that your app will get pirated. Even the biggest companies cannot prevent their stuff from getting pirated. Here are a couple practical ways to at least mitigate the damage:

• Place some logic on the server. Whether it be leader boards or other features, tying some logic into the server cuts pirate users out of some of the loop.
• Add additional features in the form of server downloads. Without a valid key, the user can’t download these additional features.

Why is it that some people don’t think twice about spending $40 on a movie night, but are too cheap to pay $2 for an app? Do they hate developers that much? While these people should be ashamed of themselves, perhaps other people live in an area where paid downloads are not an option, or they might not actually have the means to buy a lot of apps.

These users can be used as a source of good will, to help spread awareness of your app. Obviously, as a developer you need to eat, but not everyone’s going to go to some shady website to download code they can’t necessarily trust. There is a lot to be said for the convenience of regular updates and downloads from a trusted site.

What Google should have really done

If all the logic is in the client, then cracking an app is not a question of if, but when. The question is, how difficult can we make it for the pirates?

I think the current implementation of “copy protection” on Android is a complete joke and lulling many developers into a false sense of security. Your app is cracked in seconds, uploaded onto forums and download sites in minutes, and may even be re-uploaded to the market under a different name. Even worse, the verification process penalizes legitimate users when the market screws up the license check, and this happens more often than you think.

One thing Google could have done to make things a lot harder for the pirates is use a bytecode tool to generate the license library on the fly, using random permutations and injecting it everywhere into the bytecode, instead of asking the developer to use a very easily hacked method of adding some classes to their project. These checks could be generated in a slightly different form for each new release, making it much harder to replay a crack against your next release.

With an open platform, we have to accept the fact that a crack will happen. You’d need to have an AI built into the OS smart enough to determine that a modified cracked copy side-loaded onto the device is derived from a market release, and even then, that wouldn’t help you on a rooted device.

What are your thoughts on the Android License Verification Library and the current direction of the Android Market? If you haven’t yet seen it, I recommend looking at “Evading Pirates and Stopping Vampires using License Verification Library, In-App Billing, and App Engine!”

Copyright © 2012
This feed is for personal, non-commercial use only.
The use of this feed on other websites breaches copyright. If this content is not in your news reader, it makes the page you are viewing an infringement of the copyright. (Digital Fingerprint:
57093891627bcf5753cb6dde17dba8f4)

Copyright © 2012
This feed is for personal, non-commercial use only.
The use of this feed on other websites breaches copyright. If this content is not in your news reader, it makes the page you are viewing an infringement of the copyright. (Digital Fingerprint:
57093891627bcf5753cb6dde17dba8f4)