Is it possible to intercept Android's default class loading and conditionally avoid loading a class ?
My motivation is to intercept Android's default class loading process and avoid loading the class based on a condition, something like
if (!fooScope) {
throw IllegalStateException("Trying to load class from FooScope");
}
I am not intending to change where the classes are loaded from, but to have fine grained control over what classes can get loaded at what point of time, which I call Strict class loading. In this, any class which is not supposed to be loaded until certain conditions are met, should not be loaded. I am looking for ways to intercept the class loading to achieve this.
You'll probably need to use some kind of Hooking library.
like this library (https://github.com/cmzy/ZHookLib) which supports only up to Android 4.4
then you'll need to hook the loadClass(String name) method of ClassLoader.class
in order to see all the loaded classes.
but still there is the problem of the order in which the classes are loaded.
you could try to do it from a class which extends Application which might be loaded first but im not sure..
public class MyApplication extends Application {
static {
// code in static block is executed when the class is loaded
Set<Unhook> unhooks2 = ZHook.hookAllMethods(ClassLoader.class, "loadClass", new MethodHook() {...});
}
once you've hooked loadClass of ClassLoader you should be able to do what you like.
remember that there is more than one ClassLoader and also im not sure what will happen if you throw an exception.
i hope it helps
Related
I'm in the process of completely redesigning my Android app. Before, EVERYTHING was in the same class.
So I tried to redraw everything so that the code is clearer apart Admob than the doc advice to put in the Main thread, I separate the different part of my code in class. So I used two technique: I created a songleton that contains variables that I want to have access to constantly,and I call my classes via weak reference.
Here is what it looks like:
For example, the UIManager class that needs to update the game's IU have a weak reference looks like this:
private static SoftReference<UIManager> ManageUI;
static{ManageUI= new SoftReference<>(null);}
static UIManager get()
{
if(ManageUI.get()==null)
{
ManageUI= new SoftReference<>(new UIManager());
}
return ManageUI.get();
}
GameManager Manager=GameManager.getInstance();
to be able to use the findviewbyid for example I place in method argument the main class that is the mainthread
the singleton that contains all my variables that I want to have permanent access to looks like this:
private GameManager()
{}
/** Holder */
private static class Manager
{
/** Instance unique non préinitialisée */
private final static GameManager instance = new GameManager();
}
/** Point d'accès pour l'instance unique du singleton */
public static GameManager getInstance()
{
return Manager.instance;
}
To separate all in different class, I pass argument to my method so I can call au stuff belong to Activity like that:
(My main class is called GamePlay)
void OpenGlobalScene(GamePlay activity)
{
Manager.OnTitle=false;
if (!checkLayout(activity,R.id.globalscene)) {
LayoutInflater(activity,9, true);
LinearLayout GamePlan = (LinearLayout) activity.findViewById(R.id.globalscene);
GamePlan.setAlpha(Manager.AlphaBord);
}
}
For now, I have not noticed any problems except a few slownesses on old android phone 4.4.2.
Also compared to my old code were EVERYTHING was in the same class, it's much easier to change pieces of code (going to the inapp billing V3 was simpler since everything was in one class that I call like the others with weak referencre)
My questions are:
-What are the problems that such a structure might pose?
I had also chosen that structure to not load or leave in memory things that are not useful
-How are chance that Android will erase from memory an action in progress called with weak reference?
-As you can see I pass the activity has argument to the method, sometimes I pass it from a method to another. Is that fact can cause some trouble?
Thank you for your help.
Check Dagger2 is better than the clasic singleton https://developer.android.com/training/dependency-injection/dagger-android?hl=es-419
thanks for your answer and your tips. I'am gonna check this out.
Anyone else know something about consequences on memory when using weak references ?
I use a third-party API (JAudioTagger) and I would like to start an activity with an object of this API (AudioFile).
The problem is this object does not implement Parcelable or Serializable.
What is the best way to do this ?
EDIT
Google's answer : http://developer.android.com/guide/faq/framework.html
You have a few options, none of which are easy or perfect (depending on the object and use-case).
Create a custom object that extends the AudioFile object and implements either Serializable or Parcelable - which can be tedious, but not impossible. With custom objects like this, the documentation may be lacking for this option.
Someone mentioned static as an option. This can generally work well, except you are talking about Android. Android can destroy and re-create the JVM for your app at any time when it is not visible to the user. So, if this AudioFile class is playing in the background in your app, strange behavior could occur if Android decides to kill the process.
You can use an object in the Application class, but is potentially has the same issues as #2.
Use SharedPreferences and some kind of index system to retrieve the file.
You can create a class of your own, which would accept an object of type AudioFile, and populate fields with its values.
public class MyAudioFile implements Parcelable{
private File file;
//other fields...
public MyAudioFile(AudioFile audioFile){
this.file = audioFile.getFile();
//populate other fields
}
//parcelable stuff
}
I was studying the android source code and I found that there are many places in framework that use native code without using static{System.loadLibrary()}.
For example, in SystemServer.java, native method "init1(args)" is called but there is no static{System.loadLibrary()} in the file. How native code is loaded without static{System.loadLibrary()}? thanks.
The native library has to be loaded only once for the whole application, so it has probably already been loaded by another class which has been instantiated before. Note that this is not a best practice as it makes assumptions on the order by which the classes are called!
A commonly used technic to avoid this is to create a Loader class like this:
class Loader {
private static boolean done = false;
protected static synchronized void load() {
if (done)
return;
System.loadLibrary("library_name");
done = true;
}
}
This way, if you call static{Loader.load();} on every class that requires the use of native functions, you ensure that the library has been loaded (and only once).
I have created an application which uses a lot of custom objects I've created to manage parts of the application.
for example:
FacebookManager class - responsible for connecting to facebook
DatabaseManager class - responsible for application's database connection
etc...
these classes must be reachable for all application's classes.
i've extend the Application class and i'm sharing the Application instance between class so every class will be able to reach the global objects (and some more methods).
i'm wondering if this is the correct way of doing what i want, or should i create a class with static methods for the same propose.
I've read a lot about it and understood that from the memory point of view - non of these ways are best.
is there a way to save an object to the SharedPereferences and get it from another class ?
or any other idea ?
If your classes contain no states but only utility methods - you can arrange them as Utils classes, with no constructors and static methods. Otherwise, take a look at the Singleton design pattern, which is used to create a global access point for an object of class and ensures there's only one object of that class in the whole system. Hope this helps.
Recently I have started development in Java for Android.
My idea is to create one static class which will load ton of stuff on the beginning and store results for a lifetime of application.
I have been reading lot of how to share object between activities and I think the best will be to create one static class. What do you think? Should I use another approach? I am asking because I have read lot of counter opinions over the internet.
Thank you.
I'm assuming that you were referring to static fields of a class, as opposed to static class which, as Wyzard pointed out, is something completely different. As a general rule of thumb, holding information in static fields is not a good idea in Java. The reason for this is that it prevents the ability to instantiate multiple instances of whatever it is you store in the class.
In the specific case of an Android application, the best way to deal with the issue of having data stored associated with the application itself is to subclass the android.app.Application class and use it to handle application-global data:
class FooApplication extends Application
{
private String privData;
public String getPrivData() {
return privData;
}
}
You then need to declare that this class is your main application class (instead of the default Application). In the application entry in AndroidManifest.xml add the following:
<application android:name="com.example.application.FooApplication"
...>
...
</application>
You can then look up the application instance from anywhere inside your application using the method Context.getApplicationContext() which will be an instance of your Application subclass:
FooApplication app = (FooApplication)Context.getApplicationContext();
String privData = app.getPrivData();
Depending on from where you are trying to look for subclass of "Application", you may have to invoke the "getApplicationContext()" without "Context":
FooApplication app = (FooApplication)getApplicationContext();
String privData = app.getPrivData();
The problem with your solution is that you're basically creating a huge stack of globals. It's sometimes unavoidable, but it has the same type of problems globals always have- you quickly end up with hard to read code that doesn't really have a good OO breakdown. You can use this, but use it sparingly- only with important data structures that are really going to be shared between many activities.
Android provides a class called Application, which is will not be gc'ed as long as your Application isn't killed. Use this class for initialization, static classes as containers are somewhat ugly, but i can't pinpoint why that is.
I only use them as containers for constants such as bitmasks which can't be expressed as EnumSets.
As the other posts mention SharedPreferences: I think the preferences exist to store values, but not to load your structures that you need for you application. These structures should be loaded from a construct that represent or make up a model for your data's semantics.