I need to make a reference to a builtin Android Java Class in NDK c++ code.
You can do it by
cls_tm = (*env)->FindClass(env, "javax/crypto/Cipher");
I am worried someone can tamper with apk, extract the java code then create their own class with the package name javax.crypto.Cipher, and read all the sensitive data I am passing to it. I am new to Java and Android so I wanted to know if it is possible to create your own package with same name as built in packages like javax.crypto.Cipher?
It is possible to create classes with the same name. However, they do not take the place of existing classes.
Every class is loaded by a class loader. Class loaders form a hierarchy, with the "bootstrap" class loader at the very top. The class loader that loads your app's classes is created by the Android app framework; it is a child of the "system" class loader, which is a child of the bootstrap loader.
When your app references a class, it asks its class loader to find it by name. Each loader will either return a class that it defined, or ask its parent to find it. (The default behavior is to ask the parent first, but an individual loader can override this.)
javax.crypto.Cipher is part of core.jar, which is loaded by the bootstrap class loader. So unless your application's class loader decides to replace Cipher with its own version, you will get the system version.
(The JNI FindClass call is actually a bit strange. Depending on where you are when you call it, it can actually end up in the system class loader rather than your app's loader. See this section in JNI Tips for an explanation.)
Suppose you really did want to replace Cipher. You can provide your own version, and your app code will happily use it. However, when you try to pass it to some other code in core.jar, your app will fail. This is because classes loaded in the VM aren't unique by name, but rather by the combination of name and class loader. So you can't pass a Cipher+MyAppLoader into something that expects a Cipher+bootstrap.
In any event, if somebody modified your APK, they would have to re-sign it; since they don't have your private key, it wouldn't look like an app that came from you.
If somebody modified a device and replaced the system Cipher with their own version, they can do whatever they want.
Related
I want to subclass ResponseCache and use a subclass of com.android.okhttp.AndroidShimResponseCache as an internal delegate.
In particular I want to add a small pre-caching method to the class, similar to AndroidShimResponseCache.put, but with my own files in the Response to be cached.
Then I would make my class (that inherits from ResponseCache) the system default.
How can I access AndroidShimResponseCache in my code to subclass it in my application?
I'm not able to get it from any repo or library on my device.
I am trying to create unit tests for a REST client that does some API calls. The client works fine in the live application, but I can't get it to run in the test case.
Apparantly, LoaderTestCase.getLoaderResultSynchronously() could be used here (at least according to Android reference, but it will not accept my loader. The code:
public void testGetEventInfo() {
// Init some vars
...
// Create & execute loader
RESTLoader loader = new RESTLoader(getContext(),
RESTLoader.HTTPVerb.GET, action, params, LOADER_GET_NEWS);
getLoaderResultSynchronously(loader);
}
This yields the error getLoaderResultSynchronously(Loader) in the type LoaderTestCase is not applicable for the arguments (RESTLoader).
RESTLoader extends AsyncLoader. Note that I'm using the supportlibrary, maybe the Loader in there is incompatible? The documentation gives no information on this.
I've tried to solve this in several ways, though none seem to work:
Registered a listener to loader. However, the callback never triggers
Using CountdownLatch (also with a listener). Again, no trigger/countdown timeout.
Playing around with the type template (), without success.
Similar solutions on SO, though again failing to reach the listener.
Does anybody know why getLoaderResultSynchronously will not accept the loader? Or another clean way of testing the Loader, including a way to test return data? I can test handling the return data in a separate case, but I would also like to test the actual data.
Sincerely,
Have you taken a look at the source code? You'll find the following import statements:
import android.content.Loader;
import android.content.Loader.OnLoadCompleteListener;
It doesn't look like Android offers a support version for LoaderTestCase. The easiest solution would be to temporarily change to the non-support LoaderManager (that is, have your class make use of the android.content.Loader instead), test your app, and then switch back to the support implementation. You might also consider copying the testing source code into your project, import the support LoaderManager, and execute it directly. I'm not familiar with the test libraries for Loaders but it doesn't seem outwardly obvious that this would cause any major issues.
You can get sources from LoaderTestCase here, create SupportLoaderTestCase class from that sources in your test project and modify all namespaces to support library namespaces (e.g. change android.content.Loader with android.support.v4.content.Loader). Than you can extend your test case from SupportLoaderTestCase (not from LoaderTestCase) and use it without problems
The method you are trying to call (getLoaderResultSynchronously) accepts an object of type android.content.Loader. If your RESTLoader class is not of that EXACT type then you will get this error. I suspect your class directly or indirectly extends android.support.v4.content.Loader, which would explain the error.
I am not aware of a back-port of LoaderTestCase that would support testing of this type of class.
General question:
Is it possible to use a ClassLoader to replace a pre-loaded (by the system, e.g. found in Android's %android%/frameworks/base/preloaded-classes file) class?
Specific:
I am attempting to use the DexClassLoader to replace a class found in android.net.* before creating a WebView in my application. I can get a Class object, but getMethods() for example gives me an array I'd expect in the unmodified/original class implementation. Is this due to the preloaded-classes system?
Basic setup & pseudo code:
Modify android.net.* class, adding a few test methods/etc.
Compile and end up with classes.dex
jar cf mytest.jar classes.dex
Include mytest.jar in APK assets
Create DexClassLoader and get Class via loadClass()
getMethods() on Class object returns an array I'd expect to see without modifications present in #1
I can provide more details on the setup I'm using and code if needed.
No you can not. WebView is part of the boot class path, and thus the base class loader. There is nothing you can do to make it use classes in another class loader. In fact, it has already been loaded and linked to the classes it uses before your app is even launched (as part of the zygote process pre-initialization).
I'm running into more and more naming clashes between Android activities and other classes. I was wondering if you could tell me how you avoid these. Sadly, my particular naming problems are not covered in the related questions on SO.
First example
I have an activity that displays a level of the game. However, the data required for that level (background artwork, entities etc.) is stored in a separate class. Naturally, I would call the latter class Level. However, I would call the activity Level as well, because it displays levels.
Second example
I have an activity that plays back a cut scene. It basically displays several images in a row. The information which image is shown for how long is stored in a separate class. As in the previous case, I would naturally call both classes CutScene.
How would you solve these naming issues? Name the activities LevelActivity and CutSceneActivity? Name the representation classes LevelModel and CutSceneModel? Something else?
I solve those problems by either prefixing or postfixing classes with their "type", like you suggested at the end of your question :
LevelActivity, GameActivity, MainActivity, ...
CommentsListAdapter, ...
CheckNewCommentsService, ...
and so on.
But I generally do an execption for the model classes, which are the objects that contain that data : I would still name my Level model class Level, and not LevelModel, to indicate I'm manipulating, and working with, a Level.
Another solution (longer to type ^^) might be to use fully-qualified names (see here) when referencing your classes :
com.something.yourapp.activity.Level
com.something.yourapp.model.Level
With this, you always know which class is really used.
In general the best way to name android application components is to add its "component type" as suffix.
Example :-
LevelActivity (LevelActivity extends Activity)
InboxUpdateService (InboxUpdateService extends Service)
ContactsContentProvider (ContactsContentProvide extends ContentProvider)
SMSBroadcastReceiver (SMSBroadcastReceiver extends BroadcastReceiver)
By naming using above method there will be minimal chances of losing track when you're working on big code flow with lots of similar names in your application.
So, name your Activities with suffix "Activity".
And name the Class which provides Data to your LevelActivity as Level.
In Contradiction to second part of Pascal MARTIN's answer, you can also use LevelActivity and LevelInfo together. Because they offer clear difference as quoted below:
Distinguish names in such a way that the reader knows what the
differences offer
- Robert. C. Martin, author of Clean Code
But the suffix are often redundant on cognitive basis. Using only the word Level clearly emphasises that class Level offers information about Level.
So, use Level for class that provides data about Level.
NOTE : If you're using suffixes, choose one word per concept.
For Example: If you're using the suffix Info to identify classes that offer information then only Info should be used (not Data or Model) throughout your application to avoid confusions.
i wrote a View class based on ViewSwitcher and now I want to write helper classes for the view like known form the ListView: ListAdapter, ListActivity and so on..
Regarding the activity class I ran into a problem. The ListActivity forces you to add a ListView to your activity with a fixed id: #id/android:list. In my base activity class i want to archive the same, forcing a special id so that my helper classes can access the view object.
As I'm writing a general lib that could be used in various projects I can't use R.id.foobar to get the view as there's no R class. The specific project will an own R.java.
So I peeked at the source code of ListActivity and found:
View emptyView = findViewById(com.android.internal.R.id.empty);
mList = (ListView)findViewById(com.android.internal.R.id.list);
if (mList == null) {
throw new RuntimeException(
"Your content must have a ListView whose id attribute is " +
"'android.R.id.list'");
}
Ok, I could write my on R class, put it directly into my package and try to access it in the same way but I've no clue what value the id should have or need?
Also I couldn't find any R class at android_frameworks_base/core/java/com/android/internal
And even if this problem is solved: How can the user of my lib access "my id" from his layout XML?
Thanks for your help! :)
I do not think this is safe, as Android has not supplied reusable widget authors with an ID range to use for your desired purpose.
Instead, do one of the following:
Have the reuser of your widget pass in the appropriate ID.
Use Resources#getIdentifier() to look up an ID in the R.* "namespace" given the string form of the name. If you go this route, be sure to cache this result, as it is a bit expensive to look up, apparently.
If you're creating a library APK that other applications can use, then consumers of this library cannot refer to its resource IDs in XML layouts.
When an Android application is started, it loads in and caches resource information from the application APK (resources.arsc), plus the system resources (i.e. those in android.R).
Your application, running in a separate process and as a different user ID, cannot directly read the resources from other APKs.
However, if you're just using the library for your own purposes, you should be able to get a greater level of access between your APKs by signing them with the same key, or specifying the same process ID in your manifest.
you can refer to raw resources supplied by a ContentProvider over a URI, I read Jpeg's out of Zips supplied by a ContentProvider that the user downloads in a seperate apk.
the uri is something like
android.resource://name.of.component/r_file_id
Then the ContentProvider can return the appropriate resource file identification to the calling app and it can then access the file over the URI.
edit: Same keys might be necessary for this to work