How Can I Import android.util.Log from InetAddress

I cannot directly use either of the following statements

import android.util.Log;

import android.os.Environment;

from InetAddress.java in libcore/luni/src/main/java/java/net, nor can I use any file which depends on it. A member of a group that I am working with has created a class which depends on android.os.Environment and has used it successfully in other places in AOSP such as packages/apps/PackageInstaller/src/com/android/packageinstaller/PackageInstallerActivity.java

I'm not 100% certain there are not alternative methods to accomplish the tasks that the class he created is intended to accomplish, but for purposes of consistency I'd prefer to re-use his code in InetAddress.java if at all possible.

The error messages I receive are

Error: no package named android.os
Error: no package named android.util

I found this resource after searching for solutions on Google which suggested removing these lines to be able to import from standard libraries LOCAL_NO_STANDARD_LIBRARY = true;

Following this advice, I searched for parent directory closest to InetAddress.java which has an Android.mk file and tried editing it, saw that it had no lines that said LOCAL_NO_STANDARD_LIBRARY = true; but it did call JavaLibrary.mk which did contain those lines. After commenting them out and rebuilding, the following lines appeared in the output after running make:

make: Circular out/target/common/obj/JAVA_LIBRARIES/framework-base_intermediates/classes-full-debug.jar <- out/target/common/obj/JAVA_LIBRARIES/bouncycastle_intermediates/classes.jar dependency dropped.
make: Circular out/target/common/obj/JAVA_LIBRARIES/framework-base_intermediates/classes-full-debug.jar <- out/target/common/obj/JAVA_LIBRARIES/conscrypt_intermediates/classes.jar dependency dropped.
make: Circular out/target/common/obj/JAVA_LIBRARIES/framework-base_intermediates/classes-full-debug.jar <- out/target/common/obj/JAVA_LIBRARIES/core_intermediates/classes.jar dependency dropped.
make: Circular out/target/common/obj/JAVA_LIBRARIES/okhttp_intermediates/classes-full-debug.jar <- out/target/common/obj/JAVA_LIBRARIES/conscrypt_intermediates/classes.jar dependency dropped.
make: Circular out/target/common/obj/JAVA_LIBRARIES/okhttp_intermediates/classes-full-debug.jar <- out/target/common/obj/JAVA_LIBRARIES/core_intermediates/classes.jar dependency dropped.
make: *** [out/target/common/obj/JAVA_LIBRARIES/core-junit_intermediates/classes-full-debug.jar] Error 41
make: *** Waiting for unfinished jobs....
Fatal Error: Unable to find package java.lang in classpath or bootclasspath
make: *** [out/target/common/obj/JAVA_LIBRARIES/okhttp_intermediates/classes-full-debug.jar] Error 41
Fatal Error: Unable to find package java.lang in classpath or bootclasspath
make: *** [out/target/common/obj/JAVA_LIBRARIES/ext_intermediates/classes-full-debug.jar] Error 41

I can post the full make output if it's necessary, but these lines are the only lines that seem to not be part of the normal output of the build process.

Answers or comments which provide alternatives to using android.os in the first place are certainly appreciated as that is the fallback, but I'd prefer to get these imports working if at all possible.

The problem is that the Makefiles are not working properly ... for what you are trying doing.

These errors:

Error: no package named android.os
Error: no package named android.util

... mean that those packages are not on the classpath when the compiler is compiling InetAddress.java. I suspect that this is by design; i.e. to avoid or minimize circular dependencies between the Java-subset packages and the Android-specific packages. It appears that you are trying to make or inject changes to InetAddress that break that build assumption; i.e. they create a circular dependencies between modules that are intended to be built in a ordered / partially ordered sequence.

Then this:

Fatal Error: Unable to find package java.lang in classpath 
             or bootclasspath

says that you've made things worse. But it is pointing in the same general direction - a compile time classpath problem.

How to fix it?

Frankly, I don't know if it can be fixed. But if it is possible, it is likely to entail significant reworking of the android modularization and its makefiles.

Note: this is not an issue with how imports work at the linguistic level. It is all about where the compiler is looking for classes to import (i.e. where the javac command line options told it to look) and whether those classes have been compiled (yet).