Nsryjdtyk

So, I'm building an app to copy all my messages (AND mms, WITH attachments) from iOS (iTunes backup) to Android Pie (OxygenOS).

I went through Android's SmsManager.java file, and I noticed two methods:

• importTextMessage(...)


• importMultimediaMessage(...)

They appear to be the ones I'm looking for, but:

• They don't appear in the decompiled SmsManager.class file


• When I still try to use it, compiler complains


• And last, they are not documented.

So, questions. Why do they appear in SmsManager.java but not in SmsManager.class (jetbrains decompiler)? Why aren't they documented? How can I use these methods?

EDIT: I successfully restored my backup on my OnePlus 6T. If you want a working project, see here https://github.com/let-aurn/iosmessagetoandroid.

Methods annotated with @hide are not part of the public Android API and are not designed to be used by developers. They are often internal to the class only and are subject to change across Android versions.

You can call these methods via reflection, but do so with caution as they may change or be removed. You should always check when the method appeared in the .java file, when the signature changed and if/when it got removed. Then wrap your code in Android version checks where needed.

1. 
   

   The @hide javadoc annotation should only hide the method from the javadocs. However, the Android documentation states this:

   
   
   

   
   

   In general, apps should only use the officially documented parts of the classes in the SDK. In particular, this means that you should not plan to access methods or fields that are not listed in the SDK when you interact with a class via semantics such as reflection.

   
   

   
   
   

   Then it goes on to explain that reflective and other access to internal APIs may be blocked by various means.

   
   
   

   Source: Restrictions on non-SDK interfaces

   
   



2. It is possible that the methods have been removed by either modifying the source code that the ".class" files were built from, or by some bytecode manipulation after the compilation. This would have been done to prevent you writing code that depended on the internal API methods by accident.




3. If the methods aren't there (for whatever reason) in the interfaces you compiled against, you shouldn't be trying other ways to access. Even if you succeed this is liable to cause portability issues in the future.