Tim Holloway

This may help. From bash command line:
git config --global --edit
That should bring up an editor (probably vi, unless your environment is set up for emacs, nano, or something like that).

You can correct the "name = " in the [user] section and save it.

This may relate to an update I just had to make to your HelloWorld project. When using IntentFilter, you need an android:exports="true/false" attribute on the <activity> element.

Norm Radder wrote:FWIW I ran my BatteryLevel app for 2 hours  on an Android 6 tablet without anything else running. It was set to test every minute.  The battery level went from 39% to 37%.  Or about 1% per hour

Heh. MY phone can drop more than that without running a battery monitor. It also shuts down around the 37% point.

SOP for that would be to pull the battery, let everything reset itself, re-install the battery , and run complete up-and-down cycles to recalibrate it.

Except that the phone was glued together, and the battery is firmly glued in place. Now the phone is duct-taped together pending the arrival of a new unit. which, unlike the current one will NOT be from Motorola/Lenovo.

I'm not exactly sure I understand, but JSTL is not an executable language. It's a declaration language.

In other words, a "forEach" doesn't execute on the client. It's used to generate static HTML when the server converts the JSP page template to the output HTML stream (web page). So you cannot fire an event on the client, since the page hasn't even been sent to the client yet.

On the other hand, since you're still running in the server, you don't need all that stuff. Just set the info as part of your server session state.

I can't give a simple answer here, but modern devices often have different power levels of operation. For example, some processes only need wake the CPU and RAM. Some may need to wake the radio (Phone, Bluetooth, WiFi, etc.) Waking up the radio takes a LOT of power. So does activating the display screen. There may be 2-3 lower-level states that you could wake into, depending on the hardware and what service you invoke to control sleep/wake.

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.

Ah, yes. The fully-qualified package name. The "real" name of a class includes its package path. All of it. The fact that paths map to directories is actually just an artefact of how it was one of the easiest ways to make Java components maintainable using general-purpose OS tools.

Congratulations on finding this out early. It took me much longer. I was trying to use simple class names for Java web application configuration and it did not go well  

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.

Yeah. You don't want a battery monitor that wakes up so often that it drains the battery.  

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.

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:
Log.i("EditItem", "Added " + results); Log.d("EditItem", "segs " + segs);
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.

A JAR file is basically just a ZIP file, although it will often contain a META-INF directory containing extra information used by certain Java services.

That means that if you have a favorite ZIP file browser app, you can use it to see - and even extract - files from inside the JAR.

When used in a java classpath, ONLY the files/directories in the JAR are accessible as class-access objects (that includes stuff like properties files, not just class files).

HOWEVER, class resources that are in JARs that are contained INSIDE your JAR are not added to the classpath. The standard classloader does not work that way.

You might note that there are cases where that isn't true. For example, JARs placed in the /WEB-INF/libs directory of a web application JAR (WAR) are seen as part of the webapp's classpath. That's because the webapp server has special classloaders that it employs for webapps that do the access of those embedded libraries. Similarly, you can build a self-executing JAR with library JARs inside the JAR. You do this by again providing a special classloader that looks inside those JARs. The easy way to do that is use a build tool that automatically includes that extra logic and wires it into the startup code of the executable JAR.

Norm Radder wrote:Yep, most of my code is old, as am I.  Most of it continues to work and the few very infrequent updates keep it working as I want it to.  I've left off trying to keep up.  I am happy that I am able to do the few updates that I feel the apps need.  The responsiveness of my apps running on VB is OK.  

Remember, I too worked with mainframe computers before PC's! In my case, my signature Android app was written for Android 1.5. Try finding support for that! When I got back to work on it, there had been multiple versions of almost everything, including threading, database API, and the resource editor provided by Android Studio. Which has been pushing me to convert it all to Kotlin. Not today, thanks!

Though I did get a kick about how it would convert all that old anonymous inner class stuff to lambdas. Much tidier.

Keven, a "warm boot" is when you restart a system using an image that has most of the internal components configured and ready to run. A "cold" boot takes a generic OS, loads it, it then configures itself for its environment before it's ready to run. The configuration takes a LONG time in Android, so a warm boot is preferable

The Android Emulator is itself a VM - a Dalvik VM, comparable to a Java JVM. Dalvik is a lot more complicated than Java, as it implicitly sits on a copy of Linux, but that copy of Linux is tailored to the Android hardware being emulated, so it cannot simply defer directly to an Intel version of Linux.

The Dalvik VM (emulator) does have a warm start mode, if memory serves, but it's limited so cold starts are often required. To avoid that you can run the Dalvik VM within a host VM system. If you use VirtualBox, Azure, VMWare or something like that, the host VM system runs an Intel VM running Windows or Linux or whatever, then the Dalvik VM runs under that.

The recommended alternative is qemu. Unlike the other VM systems, qemu can run emulator VMs for other, non-Intel CPUs such as the ARM cpus for the raspberry Pi Single Board Computer (SBC). Or,say, an Atom CPU for Android. That allows you to get the same effect, but only one OS layer is required, rather than 2, and when you're talking a system that's slow to begin with, every reduction helps.

Caveats to the above:

1. 7 years agos is like 3 major overhauls to Android's threading APIs. They're as bad as Microsoft's database-interface-of-the-month   . Look for the newer stuff.

2. The reason VirtualBox is stuck at Android 9 is because Android recommends using qemu these days. Qemu virtualizes an actual Android hardware machine, unlike other virtualizers that run an Intel/AMD VM to then run the Android hardware as an interpreted app internally. It reduces the overhead by cutting out the middleman.

It may be comfortable to stick with old outdated ways, but software rots from the outside in, and there comes a point where trying to store new wine in old jars leaves a sour taste, so to speak. I.e., the amount of agony required to get anything done reliably using outdated resources outweighs the comfort.

I miss doing Android on Eclipse as well. But it's no longer the vendor-supported IDE. And unlike generic platforms like Java Android  isn't expected to be "write-once/develop-anywhere".

Hi Kevin,

If I read that last post properly, it's saying that iOS boots a lot faster than Android.  Well, an IBM mainframe used to boot faster than Android (almost!) One of the many reasons why you didn't just "turn a mainframe off and back on again". Android boots horrifically slow, both on native hardware and in emulation. which is why having a warm-boot image is so useful.

Somewhere in the work scheduling API for current Android there's a way to launch a thread at scheduled intervals. I don't recall details, but it's there. The bigger problem is not getting sidetracked by the 5 or 6 generations of API relating to work and threads that preceded it. The latest stuff leverages the latest JDK work support APIs.