Develop Reference

findViewById returning null TextView

This one is driving me and my team completely crazy.
We can't reproduce as it works well on all our test devices but we are getting thousands of crash reports complaining of java.lang.NullPointerException for a TextView which is obtained by findViewById in onCreate (after calling setContentView and with the correct id and layout file)
java.lang.RuntimeException: Unable to start activity ComponentInfo{xxxxxxxxxxxxx.activities.PremiumActivity}: java.lang.NullPointerException
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2097)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2122)
at android.app.ActivityThread.access$600(ActivityThread.java:140)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1228)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:137)
at android.app.ActivityThread.main(ActivityThread.java:4895)
at java.lang.reflect.Method.invokeNative(Method.java)
at java.lang.reflect.Method.invoke(Method.java:511)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:994)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:761)
at dalvik.system.NativeStart.main(NativeStart.java)
Caused by: java.lang.NullPointerException
at xxxxxxxxx.activities.PremiumActivity.onCreate(PremiumActivity.java:258)
at android.app.Activity.performCreate(Activity.java:5163)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1094)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2061)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2122)
at android.app.ActivityThread.access$600(ActivityThread.java:140)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1228)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:137)
at android.app.ActivityThread.main(ActivityThread.java:4895)
at java.lang.reflect.Method.invokeNative(Method.java)
at java.lang.reflect.Method.invoke(Method.java:511)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:994)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:761)
at dalvik.system.NativeStart.main(NativeStart.java)
Here is the onCreate method:
#Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.premium_activity_layout);
premiumInfoHeaderTextView = (TextView) findViewById(R.id.premiumHeaderTextView);
int themeColor = MPThemeManager.getSharedInstance(this).themeColor();
premiumInfoHeaderTextView.setTextColor(themeColor);
That last line is the one causing the nullPointerException (line 258)
Not sure if it can be related but the activity extends SherlockFragmentActivity
And of course premiumInfoHeaderTextView is declared as a TextView outside the onCreate method as we also use it elsewhere.

A crazy fix to a crazy bug!!
As expected in my earlier comment, the bug comes from the fact the an old layout xml file for tablets (under /res/layout-large) has beed removed in our latest version (we now use a single layout file under /res/layout).
Remember the line causing the Null Exception:
premiumInfoHeaderTextView = (TextView) findViewById(R.id.premiumHeaderTextView);
This is due to the fact that our former version layout did not have any view with id = premiumHeaderTextView and that on some tablets for users who upgraded from the previous to the new version, the old layout file has not been deleted and the system is therefore looking for id in the old /res/layout-large/premium_activity_layout.xml rather than in the new (common to all devices) /res/layout/premium_activity_layout.xml
Using crashlytics to understand that all crashes were happening on tablet devices was key to identify this "bug" which seems like a system bug on some tablets as they should not keep old resource files when the apk is upgrade.
So in summary, I copied the /res/layout/premium_activity_layout.xml to /res/layout-large in order to force tablet users to use the new layout and not an old "cached" version. That has completely fixed the bug

Way to avoid layout file naming conflict among multiple Android projects

Currently, I have an Android project, consists of 1 main project, and multiple library projects.
Just that recently, I realize that if there is same layout filename among main project and library project, bad thing can happen.
third-party-library-project
- res
- layout
- actionbar_custom_view_done_discard.xml
main-project
- res
- layout
- actionbar_custom_view_done_discard.xml
So, if in third-party-library-project, if you are having line of code in its activity,
final View customActionBarView = inflater.inflate(
R.layout.actionbar_custom_view_done_discard, null);
Error stack trace caused by layout file naming conflict
FATAL EXCEPTION: main
java.lang.RuntimeException: Unable to start activity ComponentInfo{org.yccheok.jstock.gui/group.pals.android.lib.ui.lockpattern.LockPatternActivity}: android.view.InflateException: Binary XML file line #24: Error inflating class <unknown>
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2059)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2084)
at android.app.ActivityThread.access$600(ActivityThread.java:130)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1195)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:137)
at android.app.ActivityThread.main(ActivityThread.java:4745)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:511)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:786)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:553)
at dalvik.system.NativeStart.main(Native Method)
Caused by: android.view.InflateException: Binary XML file line #24: Error inflating class <unknown>
at android.view.LayoutInflater.createView(LayoutInflater.java:613)
at com.android.internal.policy.impl.PhoneLayoutInflater.onCreateView(PhoneLayoutInflater.java:56)
at android.view.LayoutInflater.onCreateView(LayoutInflater.java:660)
at android.view.LayoutInflater.createViewFromTag(LayoutInflater.java:685)
at android.view.LayoutInflater.rInflate(LayoutInflater.java:746)
at android.view.LayoutInflater.parseInclude(LayoutInflater.java:830)
at android.view.LayoutInflater.rInflate(LayoutInflater.java:736)
at android.view.LayoutInflater.inflate(LayoutInflater.java:489)
at android.view.LayoutInflater.inflate(LayoutInflater.java:396)
at android.view.LayoutInflater.inflate(LayoutInflater.java:352)
at group.pals.android.lib.ui.lockpattern.LockPatternActivity.initActionBar(LockPatternActivity.java:356)
at group.pals.android.lib.ui.lockpattern.LockPatternActivity.onCreate(LockPatternActivity.java:347)
at android.app.Activity.performCreate(Activity.java:5008)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1079)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2023)
... 11 more
Caused by: java.lang.reflect.InvocationTargetException
at java.lang.reflect.Constructor.constructNative(Native Method)
at java.lang.reflect.Constructor.newInstance(Constructor.java:417)
at android.view.LayoutInflater.createView(LayoutInflater.java:587)
... 25 more
Caused by: android.content.res.Resources$NotFoundException: Resource is not a Drawable (color or path): TypedValue{t=0x2/d=0x7f010137 a=-1}
at android.content.res.Resources.loadDrawable(Resources.java:1892)
at android.content.res.TypedArray.getDrawable(TypedArray.java:601)
at android.widget.TextView.<init>(TextView.java:614)
at android.widget.TextView.<init>(TextView.java:442)
... 28 more
If I change the layout XML file in third-party-library-project to actionbar_custom_view_done_discard1.xml, the runtime error will gone.
This is not an issues, if the number of library projects is small. Conflict can be solved easily with simple renaming. However, when comes across huge number of library projects, what is a robust way, or strategy to overcome this problem?

Library projects need to ensure that their resource names will be distinctive and not collide with other library projects, such as by applying a prefix to those resource names.
Note that apparently the new Gradle-based build system supports resource subdirectories. I have not yet experimented with this, but if the subdirectory names form part of the resource ID, then putting your resources in a distinctive subdirectory would help to keep the resource IDs distinct (at least for non-values resources).

First I would suggest renaming your project resource file and not the 3rd party file in your first example since you may want to pull changes from the 3rd party library project again. Secondly I would suggest not using too many 3rd party library projects to begin with. From my experience the Android build system still has lots of hiccups with library projects. Things like BuildConfig.DEBUG do not work and I've had issues with library projects that contain jar file dependencies breaking the ability to run unit tests through Android instrumentation. There are tons of other bugs as well, most of them probably fairly obscure but enough of an issue that I don't suggest using library projects any more than absolutely necessary.

Android ZBar Exception only with Jenkins build

I have an android project with a QR scan activity. I use the ZBar library for this: http://sourceforge.net/projects/zbar/files/AndroidSDK/
If the project is built on a PC or Mac with exlipse, the app works fine.
If it's build by jenkins (same source from git) the app crashes.
The Exception I get is:
at controller.gui.activity.QRScanActivity.onCreate(Unknown Source)
at android.app.Activity.performCreate(Activity.java:4465)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1049)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1920)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:1981)
at android.app.ActivityThread.access$600(ActivityThread.java:123)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1147)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:137)
at android.app.ActivityThread.main(ActivityThread.java:4424)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:511)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:784)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:551)
at dalvik.system.NativeStart.main(Native Method)
Caused by: java.lang.NoSuchFieldError: no field with name='peer' signature='J' in class Lnet/sourceforge/zbar/ImageScanner;
at net.sourceforge.zbar.ImageScanner.init(Native Method)
at net.sourceforge.zbar.ImageScanner.<clinit>(Unknown Source)
... 16 more
I used the demo app for a base.
Is this a Jenkins config problem?
The Zbar library is not just a jar file, it's a C library with jni. So I have a jar file and 3 folders (for different architectures I think) and they have a libiconv.so and a libzbarjni.so files.

Add -keep class net.sourceforge.zbar.** { *; } to your proguard config file

I Dont know if you already figured it out, but this is a proguard issue. Seems your JNI classes are not being obfuscated correctly. You might need to change your proguard config to skip ZBar files.

What could be causing a ClassNotFoundException?

So I've been working on an app lately which runs fine on most devices. However, sometimes the app crashes at start up with the following error:
java.lang.RuntimeException: Unable to instantiate activity
ComponentInfo{com.mypackage.app/com.mypackage.app.activities.MainPager}:
java.lang.ClassNotFoundException: com.mypackage.app.activities.MainPager
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1995)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2096)
at android.app.ActivityThread.access$600(ActivityThread.java:138)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1207)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:213)
at android.app.ActivityThread.main(ActivityThread.java:4787)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:511)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:809)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:576)
at de.robv.android.xposed.XposedBridge.main(XposedBridge.java:115)
at dalvik.system.NativeStart.main(Native Method)
Caused by: java.lang.ClassNotFoundException:
com.mypackage.app.activities.MainPager
at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:61)
at java.lang.ClassLoader.loadClass(ClassLoader.java:501)
at java.lang.ClassLoader.loadClass(ClassLoader.java:461)
at android.app.Instrumentation.newActivity(Instrumentation.java:1053)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1986)
... 12 more
I get that this is because it can't find the class called MainPager. But how is that even possible? I mean, the class should be there.. I put it there myself :) . Why on earth is it not finding it?
EDIT: I think the cause may be that in my manifest I have android:package="com.mypackage.app" defined, but that my launch activity is in the package com.mypackage.app.activities. Currently testing this theory. Still weird that it only happens on some devices, though.
This solution won't work, since I then can't update the APK in Google Play (has to be the same package name in the manifest).

Since ADT update to revision 22 (May 2013) you have to check "Android Private Libraries" check box in Project -> Properties -> Java Build Path -> Order and Export in Eclipse for your older projects to get rid of this exception ...

in the manifest you add Activity name like this
android:name=".activities.MainPager"
because you have given package name
android:package="com.mypackage.app"

Now I am using ART runtime on Nexus 5, and I am getting ClassNotFound for some apps.
You can safely ignore those if that's the case for your users.

Programmatically creating a GridLayout from support library

In android, is it possible to create a GridLayout from the support library entirely programmatically (i.e. without writing corresponding xml)?
I create my GridLayout in a fragment (called PromotionLayoutFragment) like this:
ViewGroup fragmentView = (ViewGroup)getView();
GridLayout gridLayout = new GridLayout(fragmentView.getContext());
gridLayout.setColumnCount(2);
gridLayout.setRowCount(15);
// add views to grid ...
fragmentView.addView(gridLayout);
This works fine when i use the GridLayout class present in API level 14, but when I use the GridLayout from the support library (v7-r9), i get:
08-10 15:54:52.209: ERROR/AndroidRuntime(14687): FATAL EXCEPTION: main
java.lang.NoClassDefFoundError: android.support.v7.gridlayout.R$dimen
at android.support.v7.widget.GridLayout.<init>(GridLayout.java:255)
at android.support.v7.widget.GridLayout.<init>(GridLayout.java:274)
at android.support.v7.widget.GridLayout.<init>(GridLayout.java:282)
at net.link.redbutton.fragment.PromotionLayoutFragment.showPromotions(PromotionLayoutFragment.java:168)
at net.link.redbutton.fragment.PromotionLayoutFragment.onImageResult(PromotionLayoutFragment.java:222)
at net.link.redbutton.fragment.SchedulerResponseFragment$1.onReceiveResult(SchedulerResponseFragment.java:37)
at android.os.ResultReceiver$MyRunnable.run(ResultReceiver.java:43)
at android.os.Handler.handleCallback(Handler.java:605)
at android.os.Handler.dispatchMessage(Handler.java:92)
at android.os.Looper.loop(Looper.java:137)
at android.app.ActivityThread.main(ActivityThread.java:4441)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:511)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:784)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:551)
at dalvik.system.NativeStart.main(Native Method)

Turns out that you need to include the GridLayout support library as an Android library project (apklib), instead of a jar. I was using the maven Android SDK deployer, but there is currently an issue open regarding this.