Problem writing a debug file

I am updating an old app I use as a File Selector on Android.  I am trying to add some debug logic that writes what is written to System.out by using the System.setout method to trap all output and write it to a file.  The same code is used in over a half dozen apps that continue to work.  When I added the code to the app I am working on I get an exception:
System.err: java.io.FileNotFoundException: /storage/emulated/0/FileChooser_log_2025-01-18T144432.txt (Permission denied)
As another test I added some code to use FileWriter to write a file.  It gives the same error:
System.err: java.io.FileNotFoundException: /storage/emulated/0/Norms/empty.wps (Permission denied)

I checked that the app had Storage permissions in the Android System Settings and it has the same settings as the other apps that work.  I copied all the  <uses-permission android:name="android.permission.... statements from a working app's manifest file into the app I am working on.  No change.   <br /> <br /> What other things can I fiddle with to try and make it work?">

I am able to have the code work but do not have an explanation for what is happening.  
I added this code near the start of the onCreate method:

When the apk was installed and executed, it failed the first time and then worked the second and following times.  

Don't use System.out. As is the case for web applications, assuming that stdio services will be available is an unsafe assumption and could A) crash the app, B) wreck the app's runtime context, making it prone to unexpected failure, C) print messages out of sequence.

Use the Android Log facility, instead (import android.util.Log).

Like most loggers, you have the ability to log stuff at various levels in a fine-grained manner and use your IDE's logcat service to see the messages, filtered for your convenience.

Here's how a typical log write looks:

This produces 2 messages, one at Info ("i") level, one at Debug ("d") level. The log topic is "EditItem" and the string expression is what gets written to the log.

I have used System.out for years and have yet to have any of the events you describe happen.  The reason I like System.out is that its output can be trapped and written to a file using the System.setOut method.  
Can that be done with the Log statement?

The stdio services are only guaranteed for a JVM running in a command-line shell that provides stdio services.

That environment does not include webapps or embedded systems.

As an example, The Tomcat webapp server as shipped logs to the java.utilities.logging (JULI) subystem. In its default configuration, the JULI log writes to the JVM's stdout. However, many (not all) Tomcat distributions hijack that channel and redirect it to Tomcat's logs/catalina.out file. Except for the early stages, which route to a "localhost" log file. Other webapp servers can choose to do entirely different things, as stdio handling isn't defined for JEE. And note that logging is defined locally for each separate webapp. webapps don't log to the Tomcat log. They may leak though to stdio but it tends to be messy.

In the case of Android, it's even worse. Android devices run Linux under the covers, but it's so far under the covers that it would be hard to tell whether the base OS was Linux, BSD, or even Windows. Android discourages files and prefers (mysql) databases for persistent storage. There is no assurance that an attempt to write to stdout/stderr would not crash the system, would likely get lost and in any case, since Dalvik (the VM) launches at boot there's no mechanism for redirecting its stdio from within Android. At least safely.

As a result, Android's built-in logging system is self-contained. You use logcat to view what's recorded in the logs.

More importantly, you can filter what you see from the logs so you won't get buried in messages you're not interested in and you can set the granularity of what you see from the logcat console without having to change the application source code. Which can be invaluable in a production environment.

I suspect that your stdout writes are being captured and displayed by your IDE. But there won't be an IDE on the target tablet/phone/whatever. Dalvik is not Java, the Dalvik environment is not the same as a JVM's environment, and, coming full circle, not all Java services are supported in all Java run configurations. When you attempt to use an unsupported service, the fact that it "works" is no assurance that it will work reliably, and in extreme cases, may randomly muck up the whole system in accordance with Murphy's Law.

 stdout writes are being captured and displayed by your IDE.

The stdout's are written to a file on my tablet.  No IDE is involved.

 use logcat to view

That requires another computer to get at the logcat.  I have not found an app that runs on my device that lets me see the logcat.  It requires another computer.

As I said before I have been using stdout for years.  The output is captured in a text file on my device.   If an app abends while I am using it, some data about it is caught in a file and I don't have to worry about finding a computer to connect to for extracting the logcat.

Norm Radder wrote:The output is captured in a text file on my device.

1. HOW are you safely redirecting the machine's stdio internally on a device? Oh wait, I reviewed where this started. You were doing something that's now illegal. That's the problem with hack solutions. They break.

2. Have you considered going to the Play Store and installing a Logcat viewer?

I do have to admit that I've never needed to do what you are doing. Maybe it's just that I program paranoid ("antibugging") and catch and report faults directly in the app. But while I'm developing, there's a LOT of logging going on at various levels and the great thing about logging is that I don't have to rip it all out for performance reasons once I'm done. I can also see my app in the context of the other system services event processes, which is often critical to me.

I have several programs I have modified to run on the Android 14 device.  Three of them are able to write the debug file without any changes to the write permissions logic.  I had problems with another app writing to the file (see above)and solved it.  I am not sure the coding changes I made did it or not but it now works.

So why do some of the programs that are using the same logic and code and have the same use-permission in their manifest work and some do not?

I am now trying to migrate another program to the Android 15 device and it is not able to write to the debug file.
I'll report back when/if get it working.

Later after a 30 min break:  It is now writing the debug log file.  No code changes were done.???
Now on to the Explicit Intent not working problem.

I still think you're working harder, not smarter. And, as I said, a hack solution is often likely to work — except when you need it most.

If you MUST write to the filesystem instead of logging, I recommend you write to a blessed location such as the Documents folder.