Brown Smith

Are you frustrated by changing your test device’s proxy host name whenever your device is assigned a new IP address? Say you plan to work at 5 different coffee shops today, did you know that there is a way to set the proxy host name once, and the device will be able to proxy network at all 5 coffee shops with just a USB cable?

Here is what you will need to do

• Connect your Android device to your computer with a USB cable
• Open your computer’s terminal and run $ adb reverse tcp:8888 tcp:8888 
• Set the device’s “Proxy Host Name” to localhost  and “Proxy Port” to 8888

Voila, your device is now sending its network packets to your computer! You should now see logs for both Charles Proxy and Fiddler.

Christmas came early this year to Android developers around the globe. The Android Developer Summit blew everyone away with amazing new tools, optimizations, and so much more. Google sure ain’t kidding around when they drop a major version increment!

New dexInProcess Flag

There is now a new build flag called android.dexOptions.dexInProcess available in Android Studio 2.0. However, due to its experimental nature, it is not yet enabled by default. Michael Bendowski says it will make a huge difference! But he wants you to let him know if it works for you. (As opposed to the contrary, letting him know if it doesn’t work for you… I kid! I kid! I believe in Michael!)

You can enable the experimental flag by adding this to your build.gradle file.

New Resource Shrinker

When your debug builds go over the infamous 65k method count limit, you can ask Proguard to shrink compilation resources. However, Proguard is non-incremental and disables pre-dexing, meaning it will make your build time as fast as a snail. Every. Single. Debug. Build. The tools team addresses this problem by creating a new shrinker that is dex-friendly. It aims to be both incremental and supports pre-dexing; as a stretch goal, it hopes to improve multi-dex times when targeting pre-L devices.

You can enable the experimental shrinker by adding this to your build.gradle file.

Continue reading

Permission Nanny 0.1.1 is officially out! By the time you read this, the app and the SDK should be available on the Google Play Store and Bintray respectively.

What’s New in Permission Nanny 0.1.1

With a faster database engine and two important features, this release increments increments one minor version.

Don’t Ask Again

This release implements the “Don’t Ask Again” feature in Marshmallow; users can now ask Permission Nanny to always accept or deny permission requests directly from the dialog by checking the “Remember my preference” check box.

Deep Links

In addition, Permission Nanny now expose deep link endpoints; developers can now directly deep link into Permission Nanny. This can be useful when a user has denied a crucial permission to an app and would like to guide the user to Permission Nanny to revert his/her choice.

What’s Next

So last time I said the next release would be about documentation and tests, unfortunately I had to postpone that until the next release. Look, I even made a milestone to track that!

Permission Nanny 0.0.6 is officially out! By the time you read this, the app and the SDK should be available on the Google Play Store and Bintray respectively.

What’s New in 0.0.6

This release marks a significant milestone. Permission Nanny now supports all the APIs in LocationManager through LocationRequests; in addition, it also adds support for all the APIs in AccountManager through AccountRequests. This means that other than CAMERA, RECORD_AUDIO, READ_CALL_LOG, WRITE_CALL_LOG, ADD_VOICEMAIL, USE_SIP, PROCESS_OUTGOING_CALLS and BODY_SENSORS, all other permissions considered dangerous in Marshmallow 6.0 are now implemented and supported in Permission Nanny, allowing developers to add Runtime Permissions features to their own apps in versions prior to Marshmallow 6.0!

What’s Next

Permission Nanny is still not 1.0 software. Moving forward, I am going to add more support for the few remaining dangerous permissions. After that I’m going to focus on complete Javadoc for all public classes. Finally, I will tackle testing and stability.

Beginning with Android Gradle plugin version 1.1, developers can now write unit tests that run on the JVM in addition to the existing test framework that requires an emulator to execute. Running tests on the JVM is blazing fast compared to emulators; however, JVM tests interface with a mocked version of the Android operating system instead of a real one, so components such as databases and network cannot be fully tested with JVM tests. Hence developers often find themselves writing both sets of tests – JVM tests and Android tests.

When I’m writing tests for an application module, I often find myself duplicating the exact same set of test classes such as mocks or helpers for both Android and JVM tests. Suppose I have an Android test utility class which contains static helper methods that set up mocks’ expectations using when(mock.doSomething()).thenReturn(expectation) . However, these utilities cannot be accessed anywhere from JVM tests because their class paths are completely different –  /test vs  /androidTest. You could put these test resources in  /main  with your app code, but it is bad practice to mix test code with app code. Wouldn’t it be great if there were a location developers could place test resources that could be shared by both tests? Continue reading

After a good three and a half months, my permission management app – Permission Nanny – is officially on the Play Store. The process was very tiring, with lots of late-night coding, but I’m pretty proud of myself to be able to release an Android app in such a short amount of time! It’s completely open source too!

Check out the app on the Google Play!

Read the source on Github!