I've read (and confirmed with testing) that resource value names (Strings, Drawables, dimensions, etc.) should have a prefix at the beginning (generally the library's name) to avoid name conflicts, because a project that uses the library and declares a resource with a matching name will overwrite the library's resource.
What I'm unclear on is whether the names of attr attributes inside a <declare-styleable> should also be prefixed. Since they are wrapped within the <declare-styleable>, are they protected from over-writing? Within Java code, their resource names are automatically prefixed with the name of the <declare-styleable>, but when used within XML files, they are not.
I'm guessing that their usage is context sensitive. That in my custom Preference's code, when I call context.obtainStyledAttributes() with a specific styleable, it is only at that point that the XML attributes are interpretted as specific types. If I declare a Preference styleable attribute named "min" of type float and use it in my project, it will not matter that there is an attribute named "min" in the v7.preference library's SeekBarPreference styleable of type int, because SeekBar doesn't use my styleable when calling obtainStyledAttributes().
So if my assumption is correct, there's no reason the compiler would be consolidating attributes by name like that. But custom attribute styling is a complex beast in Android, and I'm not sure if I'm missing something in my testing. It would be nice to omit the prefixes in my library's attribute names for ease of use/documentation.
If the <declare-styleable> is defining attributes for a Style, then I think it's still safe from conflicts, because Styles don't merge. They only reference each other from their own attributes. If I understand them correctly--they are somewhat convoluted to me.
On a related note, is there any reason view IDs should be prefixed? I'm thinking yes, because my library view exists within a project's view structure and a user of the library calls findViewById() on an ID that matches one of mine, I could envision scenarios where the search turns up my view first and trips them up. But Google's own appcompat libraries take no such precaution, so I'm unsure.