0

On a project that I recently migrated from Eclipse to Android Studio I was investigating an instance of the dreaded "ClassNotFoundException: Didn't find class on path: DexPathList" (see a discussion of this type of problem here: Android ClassNotFoundException: Didn't find class on path ) and I tracked it down to the format of my AndroidManifest.xml file.

Namely, I had a fully qualified package name but the Activity name was specified as . . . 

<activity android:name="MyActivity" ...

...when what was wanted was ...

<activity android:name=".MyActivity" ...

... note the "dot" before the activity name. But none of the AndroidManifest.xml files among my Eclipse projects have this dot and they build and run fine. The other difference between my Eclipse projects and the Android Studio ones is that for the latter the app was being loaded onto a device with a newer rev of the OS - Lollipop vs Kitkat (even though that's not strictly required for the shipping version).

So my question is, is this format with the dot a new feature for the OS, or is it a requirement related to Android Studio, or what? Has it always been there but Eclipse didn't catch it? How have I gotten away with this up to now?

Community
  • 1
  • 1
user316117
  • 7,971
  • 20
  • 83
  • 158

1 Answers1

1

I tracked it down to the format of my AndroidManifest.xml file

You think that you did.

I had a fully qualified package name but the Activity name was specified as... but what I wanted was...

Those have the same meaning: that the fully-qualified class name of the activity includes the package name identified in the package attribute in the manifest.

is this format with the dot a new feature for the OS

No.

or is it a requirement related to Android Studio

No. For starters, it is not a requirement. If you putter through the several hundred projects in my book, you will find both with-dot and sans-dot declarations (along with fully-qualified package names, on occasion).

Has it always been there

My memory is fuzzy for the 2008-vintage Android builds. Both approaches have been supported for 5+ years.

How have I gotten away with this up to now?

Because both approaches are valid.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491