In the app that I'm working on I'm trying to get the Album artist from a song file. I made the query with the cursor and extract the album_artist column (https://stackoverflow.com/a/59631970), but the constant with this String (MediaStore.Audio.AudioColumns.ALBUM_ARTIST) prevent my app from compiling causing a Unresolved reference exception.
The constant has a #hide in its JavaDoc which seems to "hide" the field from outside (couldn't find a legit source to back me up here, I might be very wrong).
MediaStore source-code
What is bugging my mind is that the constant exists in the SDK, the column exists (passing the String manually works) and the constant is in the code, so why I cannot use it? If there is a better way what is it? There is no indication in the code and MediaStore.Audio.Albums.ARTIST don't give me the data that I want (gives me the "artist" not the "album artist").
Does someone know what is the proper way to get this data?
(For now I'm leaving the hard-coded String)
One solution is the answer
Which might not reliable do what you want, to guarantee reading of album_artist tag, you must read the tag manually through mediaMetadataRetriever.
You're trying to access a non-sdk interface, those are all methods, constants, classes, etc, that are not referenced in the android documentation.
Before android pie (api 28), you could attempt to use and reference these methods trough reflection, but since then google has blacklisted all usage of non-sdk interfaces. The only exception is when using non-sdk interfaces available at an specific api level, but your app must not support any bellow api levels.
The reason for such change is that non-sdk interfaces are parts of the android ecosystem that must be available at AOSP for some internal reason but are not final or available to the public. Google does not guarantee that any non-sdk interfaces wont change behavior or be deleted, breaking your app. Since developers insisted on using such interfaces in production apps, they decided to rigorously enforce the restriction.
The #hide annotation in javadoc excludes the code from the compiled javaDoc. So, when google builds its documentation, the constant not being in the android documentation is the intended behavior.
You can refer to this question
question and the documentation
ps: The constant you want to access will become part of the android sdk after android R
Related
Im currently working with the xposed framework on Android 8.0. How is it possible to find all the method names of an app to hook? For example, i want to hook the method that is called if i add a new contact. Would it be possible to reverse engineer the apk to insert an logcat output into all methods, that shows which method was called?
There a various methods for identifying the relevant methods.
The first and most important one is knowledge of the official Android API. All Java/Kotlin based apps at some point use the classes and methods defined i the API. And the most important fact is that because the Android API belongs to Android and not to the app it can not be obfuscated.
Second you can reverse engineer the app itself using tools like Jadx, apktool, Ghidra, JEB... Just make sure that the tool you use does not rename the class names (e.g. to avoid name collisions or make obfuscated class and method names better readable) or at least allows you always show you the original class and method name. Because trying to hook a method by it's name will fail if you use a name generated by the APK reversing tool.
Also a very helpful tool that allows to identify a lot o the internal on a running program is frida-trace. As long the the executed app has no anti-debugging or anti-frida measures in place you can attach frida-trace at any time to an app on a rooted device and create execution traces you can later use to hook the methods using xposed or directly using frida.
I have added multilingual toolkit for my Android & iOS projects. wherever the resource string being referred we are getting the below error.
Transparent method 'Method1()' references security critical method 'AppResource.Not_Recognized.get()'. In order for this reference to be allowed under the security transparency rules, either 'Method1()' must become security critical or safe-critical, or 'AppResource.Not_Recognized.get()' become security safe-critical or transparent.
We are having so many strings and are being referred in multiple places so adding the security critical or safe-critical attributes in all the places is not possible.
Is there any option to make the complete project as security critical or safe-critical or any other option to fix this issue.
If your project compiles, and it probably does, you can ignore this type of messages in Xamarin, right now I can't provide you with the link where it is described why, but I have already investigated problems like this before and came to conclusion that it is safe.
I am a Computer Science undergraduate student and I am creating an Android app that using an API to interact with an execution server.
The server takes a xml file and do various stuff with it(get data, process data etc.)and then gives back data as output. Both input and output are exchanged via this API.
The problem is that the API references code from javax.xml.bind, for example, JAXBContext while android doesn't have javax.xml.bind package in its core. (a well known issue)
Feasible solutions on the internet seems to be repackaging the code I need, but I don't know exactly what suppose to be.
Since the API reference classes in javax.xml.bind and javax.net, I guess I have to extract code from these 2 packages and make them part of the API (I have access to API source) and then repackage the API. However, I guess classes inside javax.xml.bind might have dependencies on other classes that not supported by Android, so does javax.net. (Please forgive me if this is stupid thought...)
So anyone know : whether there are classes, which codes in javax.xml.bind and javax.net depends on, not supported by android ?
Bit of tricky question really..
I will be really appreciated if you can provide a work around that enable a Android app to call an API that reference codes inside javax.xml.bind.
Try JiBX (http://jibx.sourceforge.net/), it's a small and fast footprint, Android compatible, XML binding framework.
I ended up with repacking those package which exists in standard Java library but not in Android. Basically, just get source code of all those missing packages and then put them into the API source and rename them into a name that is different from the original one and then change corresponding code in API that reference these methods as well (you have to use a different name, otherwise code reference methods in these package will still looking for methods in the core Library (i.e Android API)
Anyway, hope it helps. If you have the same problem.
If you have any better suggestion. Please share it!
Amazing discovery of the day: JNI on Android lets you access object fields that you're not supposed to, according to Java rules.
Is this capability to bypass access restrictions documented anywhere? Is this an official JNI behavior or specific to the Android flavor of JNI? Is this an undefined behavior? Will the OOP police come for me any moment now?
I understand that relying on unpublished object fields is inherently dangerous and may break anytime; that's not the question here.
UPDATE: looks like applications that target API28 no longer have this capability.
The problem has been described and even addressed in an article, or rather proposal published back in 2006.
Note that Javs defines SecurityManager class, but it considers all JNI calls as security breach and thus your question is a non-issue from their standpoint, like asking "why can I get elevation to Administrator when I only install some driver/service?".
But on Android, things are even more explicit. The official documentation describes this class with the following preface:
Legacy security code; do not use.
Security managers do not provide a secure environment for executing untrusted code. Untrusted code cannot be safely isolated within the Dalvik VM.
(the emphasis is theirs)
If you are looking for stronger words that guarantee that access to native fields and methods from JNI will not go away in a next version of Android, good luck to you.
On the other hand, the chances are higher that some future version of Android will change the names or signatures of some private fields and methods. Moreover, they can change the implementation such that the filed remains, but must be used differently.
Finally note, that all these considerations apply not only to private or package private methods, but also to public methods and fields that did not make it into the official documentation!
Amazing discovery of the day: JNI on Android lets you access object fields that you're not supposed to, according to Java rules.
The abbreviation JNI does not appear anywhere in the question and answers that you linked to, except as a dynamically-generated link to this very question.
Is this documented anywhere?
Any decent book on Java development should cover public, private, etc.
Is this an official JNI behavior or Android-specific?
Neither.
What is Android-specific is compile-time steps to make it difficult for you to add code in some android, java, and javax packages.
Is this an undefined behavior?
That depends on what underlying noun or concept you are tying to tying to the pronoun "this".
If "this" is "accessing private, etc. stuff", then the behavior is not undefined.
If "this" is "accessing something specific private, etc. in the Android framework", that is undefined. There are many, many versions of Android around, and many, many versions of framework classes. Their internal implementations are not identical. Anything not exposed via the Android SDK is eligible for change by Google, device manufacturers, ROM mod maintainers, etc.
Ultimately I wish to produce a compressive Contact Manager with some specific features.
I thought it would be good to experiment by extending Contact.
So using git I checked out froyo-release and tried to build it.
That didn't work so well as it contains things like
import
com.android.internal.telephony.CallerInfo;
and friends.
I'm considering the following two approaches:
Suppress the internal stuff under
the assumption that I really don't
need it.
Start with a toy Contact Manager
and implement (reinvent) everything.
My guess is that I am going about this incorrectly.
"I want that third alternative" --kirk.
Just for completeness, the new special behavior is to provide
an action list for a contact based on the types of that entities data.
A lot of the applications that ship with the platform unfortunately make use of non-public api's, which means they require a lot of hacking to build as sdk apps.
You can build them as part of a full platform build, or you can modify them to connect to the private api's via reflection or by including stubs for the private api functions that will get automatically stripped out later (as their names conflict with the real ones) - but if you want the result of your work to be something you can portably and reliably distribute other than as part of a rom upgrade, you probably need to rework things to use only public APIs.