[Android Software Development] Lanchon:
i'll be dammed... i never knew Java 5 ceased to allow you to import classes in the default package, it used to work before.

so the short answer, you already know it, you just can't...

http://stackoverflow.com/questions/283816/how-to-access-java-classes-in-the-default-package

as that link says, you can use reflection; but that is hardly a scalable solution.

another possibility is coding your patch in a different JVM language that allows importing from the default scope.

javac 1.4 would not work, cause it doesn't support annotations. but maybe some older version of a different Java compiler imports from the default package, maybe as an oversight.

ok, so regarding dexptacher, it hasn't been designed to work on obfuscated code, though it *mostly* works. stuff like static and instance fields with the same name, virtual and direct methods with the same name, fields and methods with the same name but differentiated by type or return type, etc, are handled well by dexpatcher, as long as you can actually create Java that refers to the set of those items that you need.

many improvements in this regard are in my head, but i have so many pending features and so little time, that this will probably remain mostly unimplemented.

but the limitations of the java language itself rule here and there's so much that dexpatcher can do. a more general solution is a dex rewriter that renames all obfuscated code to allow java-level manipulation (same-name things renamed, invalid identifiers renamed, etc). the rewriter would not change the meaning of the code (except if it uses reflection) and would be a pre-step to dexpatching. this tool is relatively simple to do but i don't think i have the time.

the point is that a full solution at the dexpatcher level is unfeasible, so dexpatcher will probably not go much into that direction.

so what workarounds are you left with?

well... i will assume that the classes in the default package are at least named with valid Java identifiers (because the can contain anything but .;[/ http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.2.2 - for instance, $ is a valid type name).

is this assumption true?

then an obvious workaround is to add all your patch code in the default package... ugly. but only your code; libraries you use can be invoked from the default package and libraries never contain references to clients, of course.

if for whatever reason you need to cross the default/named package barrier, some tricks can be done.

-patch source classes using patching classes in the default package.

-patching classes can import named package classes and invoke code there.

-and the reverse direction can be handled by some patch classes in the default package that will be "accessors".

accessors would follow this pattern:

import named.SomeBridge;

class SomeBridgeAccessor implements SomeBridge {
public void run() { invoke source app code from here }
}

-----

package named;

interface SomeBridge {
void run();
}

-----

static final SomeBridge someBridge = Class.forName("SomeBridgeAccessor").newInstance();

// now you can call from named package to default package:
someBridge.run();

on the other hand, if the classes in the default package are not named with valid Java identifiers, then some improvements in dexpatcher-tool might help you handle this case. so tell me.