Android Studio - Emulators wont start

I can get the application to run on my real Android Note 20.  
I can no longer get my Kotlin code to run on any emulators in the Studio.  It just keeps trying to bring up an emulator.
I closed Android Studio.  Reopened. Rebooted PC.  
It still does not start emulators.  I added a new device to the emulator and it does not start either.
I went through my set of instructions for HAMX and it looks OK.

I look at the device manager and I can't stop the emulators once they try to start.  
I once saw the name and location of files to delete to stop the emulator but I forgot where the notes are.

I'll take any suggestions.  

Thanks all,

Kevin

My first suggestion is the obvious one. Patience. The android emulator has always been very slow to start. And if you have insufficient RAM, that time will explode thanks to page thrashing.

The next one is to check the logs. You may have a failing component or, alternatively, a deployed app(s) whose startup is dragging the emulator down.

Memory is fuzzy, but I think that by default the emulator will try to restart with all the baggage from the last session unless you force it to cold-start. Alas, I can't recall how that's done though.

Tim,

I have 16 Gig of RAM.  I think it should be enough, but now maybe 32 Gig is standard.  

I forgot where the logs are.  My tutor might remember.

There were files that can be deleted in the explorer to kill the session.   I forgot how to do this.  Maybe chatGPT or YouTube can get me back to it.

I have waited over 10 minutes and the emulator does not start.

Thank you,

Kevin

Have you thought of using Oracle's VirtualBox?  I have used it for years for Android VMs.  A VM usually starts in less than 2 minutes. However in the last week or so, my adb connections to the VMs have been broken.  I have 3 Android VMs in the VirtualBox and I am not able to connect to any of them.  They worked fine last time I was testing probably at least a month ago.  Now none of them work???  Since they all have stopped I assume it is not an individual VM that is failing.  It must be something at a system level.  Either the VirtualBox software (ver 7.0.22) or Windows 10.  Meanwhile I have a need for the ability to update my Android apps. More on other thread.  https://coderanch.com/t/786729/mobile/Android-Woes

I don't know what an Oracle VM is.  I tried following the link, but there were too many things I don't know about such as LadyBug.  
I didn't realize that AS is done with Intellij.  

I got my partially written application running.  I had an error in the code so maybe it did not compile.  I'm surprised that a message did not come back saying "Hey I tried running your code, but it's broken".  

I have a lesson with my tutor in two hours.  I will close open applications and reboot before class.  

Its awful when it stops working in the middle of a tutor session because then we spend the entire time debugging.

Thanks,

Kevin

The original Android development platform was Eclipse-based. Several years back, it was switched to IntelliJ, which is bundled as part of the platform. There's little to no overlap between the two platforms, even though both are developing the same code.

VirtualBox is an Oracle product (free) that permits creating, launching, and controlling Virtual Machines. It has a GUI control panel app, but also a command-line interface. Probably the 3 major VM systems at the moment are VMWare (commercial), KVM (open-source) and VirtualBox (free, but not open-source, I think). KVM actually uses the qemu machine virtualizer in common practice.

Norm has apparently been able to launch and run Android apps in a VM, but the way he was doing it may simply no longer work. The accepted way to debug and run Android is to to use the Android emulator that comes with the development system. It simulate an actual Android device, including the standard services and utilities and GUI display. It's also notoriously slow to launch, just like real Android devices are, which is undoubtedly why Norm preferred a simple VM for just the app itself.

I just installed Ladybug myself and Ladybug can run the Android emulator in a qemu VM for better performance.

Some background and the current state of my Android project:
I just got a new Android tablet with a more modern version of Android:  14 (older tablets had 6 and 9).  I have a dozen or so apps I wrote that I want to install on the new tablet.  The first attempt failed because the app's target SDK version of Android was too low; it needs to be 23. It is a simple edit of the manifest file to set the target values so I did that, created a new apk and the app installed.  I did the same for the rest of the programs and they have installed and executed except for the one that uses Google Maps. The error message in the logcat says I need a new API key.  So that project is on hold while I investigate.  I continue to use eclipse for doing updates and some installs into the VB's VM.  Other installs I do manually with a batch file that calls the adb command.

Meanwhile I thought I would need an Android Virtual Machine running Android 14 for testing and debugging any new versions.  A problem is that I use Oracle's VirtualBox for running VMs and the youngest version of a VM I can find for VB is 9.  So Kevin's post triggered an idea to try Android Studio's emulator.  I installed AS and had it load an Android 15 VM for its emulator. That works but it is slower than the VB VM.  It takes longer to load and seems to be sticky when using it.
I had reported problems with using VB.  I have since downloaded a new VM (Android 8) and it has been working fine.  VB loads the VM in under 30 seconds and it functions OK; AS took over 50 seconds to load its VM, plus being sticky when running apps.

I have 8GB of memory which is not enough.  I have ordered 8GB more and hope that will improve performance.

IDEs are memory pigs. IDEs runnng Android are big memory pigs.

However, as I mentioned elsewhere, launching a full-bore Android emulator takes an excruciatingly long time even on a 32 GB system, though possibly not as long as rebooting my Android phone. The Android OS uses a LOT of CPU to get the full suite of processes up and running.

Android Studio Ladybug claims to run the emulator faster if you run it as a qemu VM. I'm guessing that a lot of that may come from the fact that a VM can re-spin up a warm disk image faster than the emulator can do a cold boot.

In older times you could do a warm boot of the Android emulator, but sometimes that wasn't enough.

Ass for VirtualBox and current Android, I still haven't checked. I thought VirtualBox virtual disks had their own (non-qemu) formats and own virtualizer, and I've never tried booting a foreign CPU such as Atom or ARM on it, so when I get back to my big machine I guess I'll have to remember to look into it.

Hi Tim and Norm,

I wanted to write one Android App from start to finish.  I like the idea of my project a lot.  

I missed many phone calls on my Android phone because the ring tone went to low or silent.  My mother said the same thing happened to her occasionally.  I google the issue and see people having the same problem as far back as 2011.  We don't know if its the OS, an app doing this by mistake, virus,  the up/down switch changing to the event that moves the ring tone volume, or something else.

So my application is called Ringer Guard.   I want it to wake up in intervals set up by the user.  It will set the volume of the OS setting to match Ringer Guard and then go back to sleep.

I have the GUI working pretty good.  The code is all in one messy class.

I attached the GUI of the application.  The GUI works OK, but I don't know how to do the wake up and sleep part and also write to the log.

I worked with a tutor who did a nice job, but kept rescheduling classes.  Then she raised the price and then said she can't do it any longer.  I no longer have the patience to do this on my own.  I want a tutor who will explain what needs to be done,  provide code snippets where I need them.  I like to debug between class time and add a little functionality where it looks simple.

I could post my code and ask for assistance here, but I don't think its fair to the coderanch community to go step by step with me.   There are 4 tutors in my hourly price range on preply.  I will try an introduction class with each of them until I find someone I can work with.

My tutor told me that everyone Windows PCs for Android Studio has the same performance issue.   She said all the people she knows who use an Apple workbook say the code and emulator work so fast that there is hardly any wait time or at least the same as using the device hardware. The emulators start right away. I don't have the hardware to try it or I would.  

coderanch gave me an RSVF error when I tried to submit.  I opened a new tab in chrome and I'm trying again.

Thanks,

Kevin

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.

Kevin,

I wrote a similar app several (7) years ago to check when the battery level on a tablet was below a certain level and give a warning message when it was.  It runs in the background in a way similar to what you are looking for.  It wakes up and does its tests at fixed times.    https://github.com/NormR/BatteryLevelWarning
It is written in Java.  If you have any questions about any of it, I'll be happy to help.

Then on to my android development progress:  I still use eclipse and Oracle's VirtualBox.  VB starts in less than 25 seconds from the time I open VB until the Android VM is ready for testing.  It closes in less than 5 seconds.  The problem is the youngest Android VM I can find is version 9.  I have 16GB of ram and a 2.5GHz 2 core processor running Win10.

Right now I am updating a File Selector program that knows a little bit about what my other apps do and what files they use.  For some reason the debugging code that writes to storage does not work,  I'll have to start my own thread for more details.

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".

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.  

Someone starting with a clean slate should learn the new stuff.

Tim,

I don't know what a warm boot image is.  Does this have to do with the VM?
My tutor told me that on the Apple machine the entire thing started faster.  The emulator started faster and the application moved more quickly.  I didn't see it work so I'm not too sure what she meant.

Norm,

You may have shown the battery code to me before.  I looked at in then and now and it is still above my knowledge level.  The Java code is more understandable to me than Kotlin, but I still don't know where the sleeping and waking up part happens.  

The code looks like it is in GitHub.  To run it do I have to make a new project and put the pieces of code in the correct parts of the project tree or is there a way that eclipse can work with the tree in Git?

My code is in Kotlin and one big mess in a single class.  To share it, am I better off pasting it in these chats or putting it into git.  I think I have a git account if I can find the username and pw.  I don't remember how to get code to staging and then push it to git.

I'm disappointed that my tutor left me in this mixed up place.  I think with a dozen more classes we could have cleaned up and finished the entire project.

In the old days I would have sat at my desk reading books, asking questions and experimenting.  Now I'm a lazy bones.

Kevin

Kevin,
I'll try to explain what I see in the code for the BatteryLevelWarning app. It was written over 8 years ago and it might have been by another person for all I remember about why I did what I did.  I can only discuss what the code does, not why it was written that way.  Any questions about: 'Why did you do it that way' are probably a waste of time in most cases. If anyone wants to rewrite it go ahead.
More modern versions of Android have better battery management  such that I don't use the program on my newer tablets.  

So here goes:
Looking at the manifest file I see a receiver:        <receiver   android:name=".OnAlarmReceive" />
that defines a class to receive Broadcast intents from the Alarm Manager.  More on that later.
The main activity's onCreate method receives a Bundle when it is started.  That bundle can contain info about who called it.  If the activity was not started by the receiver, it calls  findSetNextAlarm() to set the next alarm.  It computes the number of seconds to the next alarm and calls setupAlarm(duration) to call the AlarmManager's method to set the alarm.

The main class also has lots of code to manage the list of times when the alarm should be set.

When an alarm happens, the OnAlarmReceive class is called.  It creates an Intent to transfer control to the main activity with some Extra data in the Intent describing who, when and what.  When the main activity's onCreate is called, it checks the contents of the Bundle passed with the Intent, finds it was called by the AlarmReceiver and checks the voltage level.
If low, it calls code to say aloud a message about the condition.  Otherwise it gets the time when the next check needs to be made and sets an alarm for that time.

If you want more, please ask where and what.
Norm
       

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.

Norm,

I appreciate the break down of the code.

I paid for 3 lessons with Android tutors on preply.com   I'll show each one my design document, the code that shows the GUI objects running, and the kotlin code.  I'll ask them to explain how they can help me get it to work.  

Once I choose the tutors I want I'll also show them your battery code.

From preply and my tutor I found out that:  
Work Manager is the one that will not go below 15 minutes. I think that I need to use Foreground Service with a Handler.

I need to see if your code uses any of these techniques.

Thank you,

Kevin

Tim,

i appreciate the warm boot explanation.   I'll stick with the cold boot for now.

Best,

Kevin

WorkManager sounds more complicated than is needed.

Foreground services let you asynchronously perform operations that are noticeable to the user.

My battery level app did not use anything like that.  It was controlled by Alarms that started it up at designated times so that it could check the battery level.  Between the times of the checks, it was not running.  It only ran when awakened by an alarm when it would check and if the situation was OK and it would schedule a future alarm.
Its weakness was it was a chain of wakeups, it any one failed the next event would not be scheduled.  The WorkManager might solve that.

My understanding of a warm boot:  When you save the current state of the system, all the contents of the VM is copied to a file.  When the system is started again, the contents are copied back into the VM so that its state is exactly the same as when it was saved,  The system continues as if it had taken a nap, everything is as it was before the save.  A cold boot restarts the system from scratch. Everything will be renewed.  I much prefer a warn boot.

Since we have spent some time talking about the code to save stdout, I'll post it and wait for comments:


A search of where it is currently being used found the oldest version from 2013,

Norm,

I looked at the code for 5 minutes.  I see that it is doing something with sending information into files.   I don't see anything about alarms in it.

WorkManager has the limitation that the most often it can wake up is 15 minutes.  I want something could wake up every few minutes or even every minute if the user wanted to do that.

ChatGPT gave me some starting code that looks good.  

It's 12:41 am.  I need to get some sleep.  

I'll try to get back to this tomorrow afternoon and post the ChatGPT code.  I could also post my Volume Guard Kotlin code if you want to examine a mess.

Kevin

I want something could wake up every few minutes or even every minute if the user wanted to do that.

That is much more frequently than the BatteryLevel app was intended to do.  It checks at user settable times  of day like 0700, 1200, 1600 and 2100.  It can skip overnight to keep from waking anyone up.

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

Norm and Tim,

Say the application woke up every minute in the worst case.  I expect that it would take milliseconds to compare and fix the volume, Then go back to sleep again.  Most of the time it would check and go right back to sleep.  Is it the waketime that uses a lot of battery or the process that has to keep waking it up?

Kevin

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.

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

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.

With the assistance of two tutors on preply.com,  I have most of the Ringer Guard application working using WorkManager. The smallest increment of time is 15 minutes.  

There is another way to go to smaller increments.  The tutor mentioned the word a few times and I don't remember it now.  Maybe its Alarm or process or something like that.   Supposedly as I go from 14 to 1 (or maybe 0) minutes, the battery usage increases.

I don't know if the feature is needed, but I want to know how to do this so I'll have the tutor show me.  I'll have the application check if the time is below 15 minutes or not and decide which technology to use.  I'll post a message alerting the user that more battery will be used.

I have one bug now to fix.  If  the user goes to the place where the running apps are shown ...and then swipes the application up to remove it, the application runs in the background as expected when it was set to guard.   The problem is that when the user opens the app, the ringer level is shown all the way to the left and the hours and minutes are set to 0.  

I need to improve the formatting of messages in the status box.  Also I need a way for the user to clear the messages. It needs to have a vertical scroll bar added.

We need to fix the bug, add the below 15-minute approach, Refactor the code which looks like a mess, add comments,  have the tutor explain the code and files once everything is organized.  Then I'll find out how to publish the application to the Play Store.  

I'll let you know how its going as I move along.

kevin Abel wrote:
I have one bug now to fix.  If  the user goes to the place where the running apps are shown ...and then swipes the application up to remove it, the application runs in the background as expected when it was set to guard.   The problem is that when the user opens the app, the ringer level is shown all the way to the left and the hours and minutes are set to 0.  

Sounds like you're not persisting your settings. Sleep deep enough and data in RAM will be lost.

Norm, Tim and any other Kotlin developers.  I have most of the application working except that when I close the application more than once, the values of the slider object for the ringer volume, the hours and all go back to zero sound and Hours 0, Minutes 0.   The first time I close and re-open the application, the values remain the same as before it was closed.  It is what I expect.  On the second close - Open the values all go to 0.  I changed the val statements for hours and minutes to 33 and 44( I selected values other than these before closing the app) .  On the second close - open the app shows the value of 44 for minutes.  It shows 9 for hours.  I don't know where the 9 comes from.

I am posting the  code in the starting file.  I'll provide any other files you may wish to look at.  

I put an image of the GUI for reference in the Attachments tab.

I recommend you refer to the Android Lifecycle diagram, here:

https://developer.android.com/guide/components/activities/activity-lifecycle

Note that you don't have an onPause() handler.

Can you copy the contents of the logcat and paste it here that shows the problem?  Add some comments to it to point out where you think the values aren't what you want.  A good printout of values as the code executes helps me to understand the problem.

A suggestion on coding style:  Don't use String literals as keys for the put... and get... methods.  Instead define a String constant.
For example:

vs

That way the compiler will catch typos.  The compiler will not catch mistyped Strings:

Adding to Norm's suggestion, it's common to define manifest constants with names in ALL_CAPS.

That's a convention carried over from the C programming language and isn't universally used in Java, but it helps visually identify something as constant without the need to go back and look at its (final) definition.

Tim,

I'm reading the Life Cycle Document now.  It takes me time to absorb what I'm reading.  I want to read it slowly.  I have a class with my tutor tomorrow.  I hope I'll know enough by then.

Kevin

Tim,

The UPPER case on constant values is a good idea.  I used it in BASIC, C and Java\selenium.  
I didn't know the difference between val and var when I was coding so I didn't realize they were constants.  I didn't see the final keyword that is not used in Kotlin.  


I didn't spend enough time looking at the get/set method information.  I'll have to go back it it.

I'm a little frustrated with not being able to get the code to work, but its really a good thing because I'm learning a lot and that was my main goal.

Kevin

Norm,

I took a quick look at your comment about not sending "string stuff" into the set/gets  (or probably any other time I'm sending to a method.    

Good information.

Kevin

Norm,

I'll run the code and send the logcat.  How do I send it?  I'll copy it to notepad.  I used the attachments tab for images.  I don't know if it will take .txt files.

I like adding comments to code.  I don't understand the workflow yet, so all I know is that the program reads back information from what my tutor calls the "small memory".  

Thanks,

Kevin

I'm a little frustrated with not being able to get the code to work,

It is rare that a program works early on.  There is always something that you didn't think of.  I think in 50 years of programming I have  had 3 programs that I designed, coded, typed in the code, compiled and executed with the desired results the first time.
Now you are into the debugging phase.  I have used interactive debugging with a C++ project and it is nice for complicated programs. But with java I use print statements that write to a log file that can be read to understand what is happening.  You have Log statements that write to the logcat.  I haven't used the filtering that a fancy IDE provides.  I use the adb command to pull off the logcat and get a 20-30M file to read.  When debugging the IBM VM OS in the 80s, I used to get a core dump on paper that measured in inches.  Today everything has  programs to help scan a dump.

FWIW Here is a sample of the print out from a program I am currently debugging ( BLW = BatteryLevelWarning)  I like to keep the text short so I abbreviate a lot.

BLW onCreate() at 2025-01-30 T 10:19:26
BLW onCreate  times=07:15, 10:00, 15:00, 15:30, 16:00, 16:30, 17:00, 17:30, 18:00, 21:45
BLW onCreate() intent=Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=com.normsstuff.batterylevelwarning/.BatteryLevelWarning bnds=[696,761][888,999] }
>>data=null
>>extras=null
savedInstanceState=null
BLW onResume at 2025-01-30 T 10:19:27
BLW button clicked runningAlarm=false, alarmPI=null at 2025-01-30 T 10:19:32
BLW Set the alarm for 60 seconds at 2025-01-30 T 10:19:32 alarm at Jan 30 10:20
BLW onPause() at 2025-01-30 T 10:19:34
onPause intent=Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=com.normsstuff.batterylevelwarning/.BatteryLevelWarning bnds=[696,761][888,999] }
BLW onDestroy at 2025-01-30 T 10:19:34
   1 minute
BLW onCreate() at 2025-01-30 T 10:20:38
BLW onCreate  times=07:15, 10:00, 15:00, 15:30, 16:00, 16:30, 17:00, 17:30, 18:00, 21:45
BLW onCreate() intent=Intent { flg=0x10000000 cmp=com.normsstuff.batterylevelwarning/.BatteryLevelWarning (has extras) }
>>data=null
>>extras=Bundle[mParcelledData.dataSize=132]
savedInstanceState=null
>>bndl keySet=[timeOfAlarm, StartedBy]
BLW startedBy=OnAlarmReceive, timeOfAlarm=Jan 30 10:20 at 2025-01-30 T 10:20:38  <<<<<<<<<<<<< NOTE
Battery level=89
BLW Set the alarm for 60 seconds at 2025-01-30 T 10:20:38 alarm at Jan 30 10:21

  ??? 10 minutes later <<<<<<<<<<<<<<  Manually opened
BLW onResume at 2025-01-30 T 10:30:24
BLW onPause() at 2025-01-30 T 10:30:24
onPause intent=Intent { flg=0x10000000 cmp=com.normsstuff.batterylevelwarning/.BatteryLevelWarning (has extras) }
BLW onSaveInstanceState() at 2025-01-30 T 10:30:24
BLW onResume at 2025-01-30 T 10:30:24
BLW TTS onInit status=0
BLW runnable calling finish() at 2025-01-30 T 10:30:30
BLW onPause() at 2025-01-30 T 10:30:30
onPause intent=Intent { flg=0x10000000 cmp=com.normsstuff.batterylevelwarning/.BatteryLevelWarning (has extras) }
BLW onDestroy at 2025-01-30 T 10:30:30

BLW onCreate() at 2025-01-30 T 10:30:33
BLW onCreate  times=07:15, 10:00, 15:00, 15:30, 16:00, 16:30, 17:00, 17:30, 18:00, 21:45
BLW onCreate() intent=Intent { flg=0x10000000 cmp=com.normsstuff.batterylevelwarning/.BatteryLevelWarning (has extras) }
>>data=null
>>extras=Bundle[mParcelledData.dataSize=132]
savedInstanceState=null
>>bndl keySet=[timeOfAlarm, StartedBy]
BLW startedBy=OnAlarmReceive, timeOfAlarm=Jan 30 10:21 at 2025-01-30 T 10:30:33  <<<<<<< NOTE timeOfAlarm is 9 minutes ago
Battery level=89
BLW Set the alarm for 60 seconds at 2025-01-30 T 10:30:34 alarm at Jan 30 10:31
BLW onResume at 2025-01-30 T 10:30:34
BLW TTS onInit status=0
BLW runnable calling finish() at 2025-01-30 T 10:30:40
BLW onPause() at 2025-01-30 T 10:30:40
onPause intent=Intent { flg=0x10000000 cmp=com.normsstuff.batterylevelwarning/.BatteryLevelWarning (has extras) }
BLW onDestroy at 2025-01-30 T 10:30:40

BLW onCreate() at 2025-01-30 T 10:30:54
BLW onCreate  times=07:15, 10:00, 15:00, 15:30, 16:00, 16:30, 17:00, 17:30, 18:00, 21:45
BLW onCreate() intent=Intent { flg=0x10000000 cmp=com.normsstuff.batterylevelwarning/.BatteryLevelWarning (has extras) }
>>data=null
>>extras=Bundle[mParcelledData.dataSize=80]
savedInstanceState=null
>>bndl keySet=[Notify at]
BLW startedBy=null, timeOfAlarm=null at 2025-01-30 T 10:30:54
BLW onResume at 2025-01-30 T 10:30:54
BLW button clicked runningAlarm=true, alarmPI=null at 2025-01-30 T 10:30:55
BLW cancelled Alarm at 2025-01-30 T 10:30:55
BLW onPause() at 2025-01-30 T 10:30:58
onPause intent=Intent { flg=0x10000000 cmp=com.normsstuff.batterylevelwarning/.BatteryLevelWarning (has extras) }
BLW onDestroy at 2025-01-30 T 10:30:58

Norm,

I'm reading about the adb command .  It looks as if I use adb logcat.  I tried it in the CMD window and it wasn't recognized.  Where do I launch it?

I copied the logcat using CTRL + C and put it in a word file.  I wanted to capture all of the colors, but I'd have to use something like snagit and I don't want to pay the $65 for it.  Maybe I should.  

Do you know where the logcats are stored along with the colorization?

Thanks,

Kevin

My environment does not support colors.  Sounds nice, but I have no idea how to preserve the colors.

I use batch files to call the adb command with a full path.  The >> concatenates the output to the designated file:

@rem  Run adb

D:\AndroidDevelopment\adt-bundle-windows-x86_64-20140702\sdk\platform-tools\adb.exe devices

D:\AndroidDevelopment\adt-bundle-windows-x86_64-20140702\sdk\platform-tools\adb.exe logcat >> Nexus7Logcat.txt

MORE

That is with the android device connect to my PC with a USB cable.  The adb command does not end so I let it run a while and then close the window or use the Task Manager to End Task on the adb command.