error: use of undeclared identifier ‘LED_ADJUSTMENT_G’

After synching my source with AOKP for Nougat 7.1.2, I ran into this error when trying to build for the JFLTETMO:

[CODE]
target thumb C: lights.MSM8960 <= hardware/samsung/liblights/lights.c
hardware/samsung/liblights/lights.c:215:40: error: use of undeclared identifier ‘LED_ADJUSTMENT_R’
int red = ((color >> 16) & 0xFF) * LED_ADJUSTMENT_R;
^
hardware/samsung/liblights/lights.c:216:41: error: use of undeclared identifier ‘LED_ADJUSTMENT_G’
int green = ((color >> 8) & 0xFF) * LED_ADJUSTMENT_G;
^
hardware/samsung/liblights/lights.c:217:33: error: use of undeclared identifier ‘LED_ADJUSTMENT_B’
int blue = (color & 0xFF) * LED_ADJUSTMENT_B;
^
hardware/samsung/liblights/lights.c:258:31: error: use of undeclared identifier ‘LED_BRIGHTNESS_BATTERY’
adjusted_brightness = LED_BRIGHTNESS_BATTERY;
^
hardware/samsung/liblights/lights.c:261:31: error: use of undeclared identifier ‘LED_BRIGHTNESS_NOTIFICATION’
adjusted_brightness = LED_BRIGHTNESS_NOTIFICATION;
^
hardware/samsung/liblights/lights.c:264:31: error: use of undeclared identifier ‘LED_BRIGHTNESS_ATTENTION’
adjusted_brightness = LED_BRIGHTNESS_ATTENTION;
^
6 errors generated.
[/CODE]

Pretty simple, as we have talked about this before. In the past, I actually removed these lines from the light.c file, but this time I decided I would leave them in, and declare them instead. Essentially, the outcome is the same though for this build.

What these lines do is allow for custom liblight configurations. Perhaps a particular phone or tablet has a built in LED notification light where the green is brighter than the red or blue. In that case, every mixed color made from those LEDs will look strange. This gives the rom maker the option to “dim” down one or all three of the lights. The same applies for the brightness of the battery, notification, or attention lights.

As you can see below, I just declared them with the default values:

[CODE]
return err;
}

// WJH declaring these undeclared lights.
int LED_ADJUSTMENT_R = 1;
int LED_ADJUSTMENT_G = 1;
int LED_ADJUSTMENT_B = 1;
// WJH declaring these undeclared lights.

static int calibrate_color(int color, int brightness)
{
int red = ((color >> 16) & 0xFF) * LED_ADJUSTMENT_R;
int green = ((color >> 8) & 0xFF) * LED_ADJUSTMENT_G;
int blue = (color & 0xFF) * LED_ADJUSTMENT_B;

return (((red * brightness) / 255) << 16) + (((green * brightness) / 255) << 8) + ((blue * brightness) / 255);
}

…………EDITED FOR SPACE………………

led->delay_off = state->flashOffMS;
break;
default:
return -EINVAL;
}

// WJH declaring these brightness adjustments.
int LED_BRIGHTNESS_BATTERY = 255;
int LED_BRIGHTNESS_NOTIFICATION = 255;
int LED_BRIGHTNESS_ATTENTION = 255;
// WJH declaring these brightness adjustments.

switch (type) {
case TYPE_BATTERY:
adjusted_brightness = LED_BRIGHTNESS_BATTERY;
break;
case TYPE_NOTIFICATION:
adjusted_brightness = LED_BRIGHTNESS_NOTIFICATION;
break;
case TYPE_ATTENTION:
adjusted_brightness = LED_BRIGHTNESS_ATTENTION;
break;
default:
adjusted_brightness = 255;
}
[/CODE]

 

For the LED_ADJUSTMENT_R/G/B, I gave a value of 1. If you look at the math, it is used in the next formulae as (a & b) * LED_ADJUSTMENT_R/G/B. So if I set a value of 0, then the mathmatical outcome will be 0. If I set it at 1, then it will always be (a & b).

For the LED_BRIGHTNESS_BATTERY and so forth, I used the adjusted_brightness of 255, which is the default.

For both of these sets, I could have just removed them all together. But I build for several phones using the same source. By leaving them in, I should have an error if the device tree declared what is already declared in the lights.c file. Or at least that is my hope. In that case, then I could remove my handy work to make room for the actual values.

Linux – keep it simple.

LG G4 on SlimRoms: delete the pin key in TWRP!

In my last post, I told the epic adventure of figuring out how to get into recovery mode so I could fix my unbooting phone. I had performed a backup of SlimRoms before trying to flash OmniRom, and since I was back into TWRP, I restored my backup. Figuring all was well, I rebooted.

Everything booted up great. However, once into the rom, it asked for my screen lock pin, as usual. But unlike the normal response, it kept saying that I was entering the wrong pin. I tried my pin, my old pin, and no pin. No luck. It wasn’t working.

There are a lot of articles on this, and this will not be much new, however, the names of my lock files were different than the article I read, so I am posting the names of the files here in case I forget when this happens to me again. (Most of this blog is simply my own scratchpad of notes to help me remember something….)

So, power off the phone, and jump back into TWRP (see the previous post if you need help with that). In TWRP, go to Advanced – > File Manager.

Scroll down to the /data folder. Open the /system folder and look at the contents.

On my phone I had to delete these files to disable the lock:

gatekeeper.password.key

gatekeeper.pattern.key

locksettings.db

locksettings.db-shm

locksettings.db-wal

After deleting these five files in the TWRP file manager, I then rebooted the phone. Sure enough, now I had no lock screen settings nor pin in the ROM. Back in action! I, of course, immediately set up a new lock screen and pin for security purposes. Hopefully that helps you too!

Linux – keep it simple.

How to get to TWRP on a LG G4 with the hardware buttons….

This is something that should be easy. Really easy. However, it took me a while to find this on the web, and since it did, I’m posting it here too. On XDA, there is a thread about this, intermingled with numerous other threads that say different or sometimes erroneous information.

Back story:

I flashed my LG G4 T-Mobile (H811) phone with a new custom rom I built – OmniRom. Only it didn’t boot. Don’t know why yet, I’m making an engineering build now so I can use ADB to figure that out. As far as I knew, the only ways to get to TWRP were to choose such from your power down menu, or use ADB to reboot into recovery. I thought all was lost, because ADB was not set to on in my custom build, and there was no way to get to TWRP, or so I thought.

I started trying every button combination I could think of.

Found the IMEI screen:

This did lead me to an interesting discovery, if you press Volume down + Volume up + Power, then, when you see the LG logo, release Power (but hold the volumes) wait a second, then press and hold the Power button with the volume buttons, you go into a special IEMI screen that displays a barcode with your IMEI on it.

But I didn’t need that. Quite frankly, you can just open the case and read the sticker to know your IMEI, so this was useless to me, but interesting enough for me to note it here.

After multiple tries, I found the “Factory Reset” screen by holding Volume down + Power, then, when you see the LG logo, release Power (but hold the volume) wait a second, then press and hold the Power button with the volume button. This will take you to the “Factory Reset” screen.  I thought that was no good. I wanted to get to the recovery mode.

However, feeling frustrated and hopeless, I chose “yes” for the factory reset. Interestingly, it then flashed the screen, and took me to TWRP!

Believe me, I was very happy!

So, if TWRP is installed properly, then you can get there by entering “Factory Reset” mode, and selecting “yes”. Simply confusing, right? I guess when you say “yes” on stock firmware, it boots stock recovery and performs a factory reset, but since there is no stock recovery, it enters TWRP with a reset flag, which TWRP doesn’t use. Makes sense, I guess. Too bad they just didn’t make it so when you push volume down and the power button during startup that it would just take you to recovery mode like every other Android phone on the market.

Linux – keep it simple.

SlimRoms 7.1.2 on the H811 LG G4!

Praise God! My SlimRoms Nougat ROM for the LG G4 H811 is finally working!

It’s always fun to try building for a new device, but this one was particularly interesting, as it was my first non-Samsung build! Not to mention the 64 bit arch, which just makes the learning process all that much more fun! Be sure to give it a try, you can find it on XDA, or here on my site under “Homemade Roms” from the title bar menu.

Linux – keep it simple.

Fixing the blank developer settings on SlimRoms Nougat

After building SlimRoms Nougat for the H811 (LG G4 T-Mobile), I ran into an odd artifact: when you enabled and opened the developer settings, it would be blank, or crash. I had absolutely no idea why that would be, nor where to begin looking into a fix.

So, I hopped over to SlimRoms’ gerrit: https://review.slimroms.org/#/q/status:merged

Once there, I looked at merged (accepted or fixed) labels, and typed “developer” in the search box. A lot of things came up, but there was a noticeable trend among the contenders, a crash or ANR report when opening the developer settings.

In every case they used the same fix, so I decided to give it a try. It looks like the common factor in every case was the FRP, or factory reset protection in the system.prop files for the devices. I took a look at mine:

# Factory Reset Protection
PRODUCT_PROPERTY_OVERRIDES += \
ro.frp.pst=/dev/block/bootdevice/by-name/persistent

and edited them as such (just commented out) :

# Factory Reset Protection
# PRODUCT_PROPERTY_OVERRIDES += \
# ro.frp.pst=/dev/block/bootdevice/by-name/persistent
# WJH commented out as this prevents the developer options from opening.

And it was fixed! It’s great when the fix is so easy!

Linux – keep it simple!

Signing and installing your MechDome converted app on a simulated iPhone

In our last post, I talked about a really neat website: MechDome, which automatically converts your Android app into an iPhone application. If you haven’t read that article, I suggest you do to learn more about MechDome, which I think is going to be very big for Android developers in general. At the end of our last post, we had downloaded our converted app and run it in an iPhone simulator on our virtual Apple computer. In that post, though, I skipped all of the details of how we do that, and I would like to take a look at that question now.

So, get your Apple fired up (online, virtual, physical, etc.) and download your converted app from MechDome!

Now that you have your app downloaded, go ahead and launch Xcode. If you don’t have Xcode, it can be installed from the iStore. Once Xcode is open, go ahead and edit your preferences.

Xcode –> Preferences –> Accounts

If this is the first time you’ve been here, like it was for me, then it will be blank. press the “+” sign at the bottom and add your Apple ID account.

Once your Apple ID is added, you can now select it, and click on “View Details”. In the resulting popup, click “Create” for iOS developement. This will create the certificate you need for “signing” your test apps on your local simulator. There is not much to tell you how it went, but if the button to create disappears, it worked, so click “done”.

Now you are ready to launch the simulator. There is probably a better way to do this, but here is the simplest methode I found. Since you have Xcode open, go ahead and launch a new project. It will load fairly quickly with a default empty project. Now, press the play button at the top of the screen, which will automatically launch the simulator, boot the iPhone, and launch your empty app project.

Once that is open, you are litterally done with Xcode, so you can quite or close it, and the simulated iPhone will stay open.

Click on the iPhone window, and from the top menu, select Hardware –> Home to get back to the iPhone home screen.

Now open your OSX terminal. You can open it from the launcher by typing term and clicking on the terminal icon.

In your terminal, navigate to the downloaded zip file. For me, it was in “Downloads” and looked like an “app” but it was a directory.

$ cd Downloads

$ ls

stuff
stuff
stuff
Hourglass.app
stuff
etc….

Now, find your new certificate (key) to sign the app with:

$ security find-identity -p codesigning -v login.keychain
1) ALPHANUMERIC4404038dkldsf03893 “NAMEOFCERT: APPLEID@EMAIL (MOREALPHANUMERIC)”
2) ALPHANUMERIC4404038dkldsf03893 “NAMEOFCERT: APPLEID@EMAIL (MOREALPHANUMERIC)”
3) ALPHANUMERIC4404038dkldsf03893 “NAMEOFCERT: APPLEID@EMAIL (MOREALPHANUMERIC)”

And set the default keychain:

$ security default-keychain -s login.keychain

And sign your “app”:

$ codesign -vfs “NAMEOFCERT: APPLEID@EMAIL (MOREALPHANUMERIC)” –keychain login.keychain ./Hourglass.app/

Now that it is signed, you can install it into the already running iPhone simulator with the following:

$ xcrun simctl install booted Hourglass.app/

You should see it show up on your iPhone home screen, but it may be on one of the other screens, so swipe left and right to find it. Once you found it, go ahead and click on it to launch the app! There you go! Barring any other issues, it should work as expected.

hourglass

Apple – er, uh, wait! Linux – keep it simple!

 

MechDome: Run your Android apps on iPhones and iPads!

As an open source developer of simple Android applications, I can’t tell you how ecstatic I am about a new website: MechDome  (https://www.mechdome.com/). Finally, a one stop shop to turn your Android app into one that can be used on iOS devices, in minutes!

Can this really be? Is it really that simple? Drag and drop your Android apk file into their website and it spits out an iOS application? Well, I decided to try it for myself, and I’ve devoted this entire post to my experience.

TLDR: MechDome ROCKS! It successfully converted my opensource app: Hourglass, into an app for iPhones. If you are an Android developer, you should head over to MechDome right now!

Still with me? Great, then here are my thoughts on MechDome ….

Website Experience:

mechdome_home

The MechDome website is intuitively laid out in an informative and well thought out manner. From the opening page you will see all the information you need to get started, as well as informative placards telling you what MechDome will do for your app, namely convert it from a native Android apk to a native iOS application.

mechdome_intro

After clicking “Create App” at the top, you are asked to sign up for an account. The process is clean and intuitive, and I really liked the color scheme. Perhaps one of the best features of the website is the modern user interface and clean look.

I also tested the website out on my cell phone, and it worked beautifully.
mechdome_icon

Within a minute I had my app uploaded and was ready to test out this process. You have a couple of options about Firebase or Google ads, etc., as well as the option to use a custom icon. I think the choice to use a custom icon is great, as you may want something that looks more “iPhone-ish” or something to differentiate between your Android and iOS applications visually. After choosing your options, press save.

Once your settings are properly set, all you have to do is click the Simulator button. Presumably, when they open up the options to go to the Apple store, you can simply press the iOS button instead, but for now, free accounts are only able to upload one app for the simulator.

This is the only “problem” I saw with the website. After clicking the Simulator button, the button starts spinning, but there is no sort of progress report. After a while of waiting I ended up closing the browser, opening the page again and found the button still spinning, so I left the screen to do some research. After a few minutes, however, I received an email telling me that my app was ready for download.

So if you convert an app, after clicking Simulator, you can go about your business knowing that an email will be sent to you when your app is ready. That is really convenient. I do think the website should indicate that, though, after you click the Simulator button.

I tried this twice with my two email accounts. The first app I tested was done in a few minutes. The second app I tested was not done for several hours. Both of the apps were about the same size, albeit one was a little more complicated than the other.

mechdome_appready

Once your app is ready, the Simulator button changes from the orange “refresh” symbol to a green “download” symbol to let you know your app is ready for download.

A quick tap of the download button and I had a shiny new zip folder on my hard drive. Simple, short, sweet!

Now all I had to do is test it…..

App conversion:

It actually took me a while to get the hang of how to use an Apple computer so I could test the app that I converted. Since that is a bit of a rabbit trail, I will save that for the next post. Here I will just talk about how well the app conversion worked.

As I said before, I used my two email accounts to “cheat” and use MechDome twice. Currently, free accounts only get one trial download/conversion for simulator use only. Both apps that I tested did work rather well, so I will only discuss the open source app that I tested, which was my Hourglass app, available on F-Droid and the Google Play Store.

Here’s a few screen shots of my app in iOS action:

This slideshow requires JavaScript.

Overall the app worked great! It looked pretty close to what it looks like on Android, and as far as I could tell, every part of the app, every button, every slider, etc., worked flawlessly.

Notifications, however, were a bit different. Not wrong, just different. First, as you can see in the slideshow, I was prompted to ask if I would allow this app to send notifications or not. Choosing yes allowed the notification to pass through, and you could see it in the notifications bar, if you pull the bar down. When the timer on the app reaches 0:00, it is supposed to have a popup to tell you that your timer is up, but that didn’t happen. If the app was open, then that would transpire, but not if the app was closed. However, the sounds still played, so it seems to still function great as a background timer.

The other app I converted was a customer feedback type of app, which was not open source, so there are no pictures of it here, sorry. An interesting note, it used parse extensively, and seemed to work flawlessly. This proved to me that parse, networking, and intents were working great! The only oddity was the color of the “stars” for the ratings. In the Android version, the stars were orange/yellow, but in the iOS version, the stars were an odd gray color. Still functional, just a bit of a visual oddity. Overall, I was really impressed. Two thumbs way up from this Android developer!

Open source and Pricing potential:

I exchanged a few emails with the MechDome staff and was really impressed by how quickly they responded, as well as their professionalism, enthusiasm, and helpful attitude. In those emails I asked them about general pricing and open source development. They have not publicly finalized any pricing options, but it sounds like they plan on a tier subscriptions. Perhaps those who do multiple apps, or apps of a certain magnitude will fall under larger “tiers” and be charge extra.

Within our emails, we had a brief discussion in which I was proposing an open source developer account option. While I cannot speak on their behalf, they did seem very favorable to supporting open source development. Obviously, if you are making free applications, it doesn’t work to pay money to convert them for the iOS systems. They were curious to know what my thoughts are for what an open source developer account might look like.

These sort of things are probably best left to bean counters who usually handle this thing, but here are my thoughts on how to best support open source development:

  • Ideal: Give users the opportunity to create an open source developer account that can convert a limited number of open source apps per month, such as two or three, for free. No subscription costs, and if the account stays active, then it will not expire.
  • Less than ideal, but still helpful: Give users who already have paid subscriptions the ability to convert open source applications without counting against their monthly quota or subscription.
  • A one time setup cost: Another option might be a one time cost, rather than a subscription, for an open source account. E.g., a $25 setup fee for open source users to set up a developer account.

With either of the above options they will help support open source development. However, I suspect that if it costs anything for a subscription, a lot of open source developers will not be able to participate.

For instance, my open source applications and software work garner me $0 currently. I receive no donations currently, and do not get paid for my open source work, I don’t currently support advertisements, because this is my hobby. So if the subscription costs too much, I would not be able to maintain the subscription.

But, if there was a one time fee (like there is to get a Google developer account and put apps on the Play Store), or a free account with limited use for the open source developer, then I would be all in! Obviously, any account that used the software improperly, to convert closed source materials for free would need to be prosecuted, etc., but that is something I’m sure MechDome  is already looking at from a legal standpoint.

These are just my thoughts, and they do not reflect MechDome‘s opinion on the matter, as that remains to be seen. Hopefully they will consider the open source community and help it thrive by allowing some sort of use of their conversion software, because MechDome has proven to me to be exceptional when it comes to quality and customer service so far! Now all we have to wait on is their pricing.

In the mean time, head over to MechDome and try converting an app yourself! It works great! If you have trouble running that app in the simulator, be sure to check out my next post!

Linux – keep it simple.

P.S. I don’t want to sound like a broken record, MechDome is not offering me any special deals, payment, or benefits to write this, I just really liked my test run of their conversion software on their website.

undeclared identifier ‘POWER_HINT_LAUNCH_BOOST’

So, a new one for me. I’m building a rom for the H811, the T-Mobile variant of the LG G4. Currently building the tried and true AOKP 7.1.2 that I have used for my other phones, and I ran into an error:

[CODE]
target thumb C: power.msm8992_32 <= device/qcom/common/power/power-8992.c
device/qcom/common/power/power-8992.c:211:17: error: use of undeclared identifier 'POWER_HINT_LAUNCH_BOOST'; did you mean 'POWER_HINT_CPU_BOOST'?
if (hint == POWER_HINT_LAUNCH_BOOST) {
^~~~~~~~~~~~~~~~~~~~~~~
POWER_HINT_CPU_BOOST
hardware/libhardware/include/hardware/power.h:71:5: note: 'POWER_HINT_CPU_BOOST' declared here
POWER_HINT_CPU_BOOST = 0x00000110,
^
1 error generated.
[/CODE]

The suggested option was to change POWER_HINT_LAUNCH_BOOST to POWER_HINT_CPU_BOOST, but I didn't like that, since just a dozen lines later in the code, there was already an if/then statement for POWER_HINT_CPU_BOOST. Esentially, we need to either declare POWER_HINT_LAUNCH_BOOST, or get rid of it in our code. In this case, I decided to scrap it because if it was needed, then it would have existed already. Strange logic perhaps, but what we see is that if it is not called, it will not return anything anyways. If it is called, it just supplies some information that I think we can live without.

[/CODE]
// WJH was POWER_HINT_LAUNCH_BOOST
// WJH if (hint == POWER_HINT_LAUNCH_BOOST) {
// WJH launch_boost_info_t *info = (launch_boost_info_t *)data;
// WJH if (info == NULL) {
// WJH ALOGE("Invalid argument for launch boost");
// WJH return HINT_HANDLED;
// WJH }

// WJH ALOGV("LAUNCH_BOOST: %s (pid=%d)", info->packageName, info->pid);

// WJH int duration = 2000;
// WJH int resources[] = { SCHED_BOOST_ON, 0x20C };

// WJH start_prefetch(info->pid, info->packageName);
// WJH interaction(duration, ARRAY_SIZE(resources), resources);

// WJH return HINT_HANDLED;
// WJH }

if (hint == POWER_HINT_CPU_BOOST) {
int duration = *(int32_t *)data / 1000;
int resources[] = { SCHED_BOOST_ON };
………….EDITED FOR SPACE…………….
[/CODE]

That will cut it out of the loop, which means the loss of a feature, but I think it is one we can live without.

Linux – keep it simple.

Setting up libGDX for Android Studio on Ubuntu

Every one else is probably brighter than me. However, after reading the instructions over and over again, and then attempting to follow them, it just wasn’t working. All I wanted to do was start a libGDX project in Android Studio. I finally figured out where I went wrong, so here is the step by step for any one else that gets stuck like I did. Please read all the instructions first, because step 5 becomes step 1, but doesn’t make sense unless you read them in this order:

  1. Go to https://libgdx.badlogicgames.com/download.html and click “Download Setup App”.
  2. A jar is downloaded. Don’t try to import it, or something of that nature. Clicking on it is no good either. Simply open a terminal window and cd to the Downloads directory. Once you are there, type: $ java -jar ./gdx-setup.jar
  3. A window will pop up. Fill in the usual blanks to name your app.
  4. For the Android SDK field, open Android Studio, and click File –> Project Structure. That first field is the Android SDK.
  5. For the folder to put the newly created app in, be sure that you choose a folder that is empty, because it will wipe out everything in that folder. So I recommend you make a folder for it first!
  6. Uncheck the things you don’t need, like IOS, HTML, etc, and click generate.
  7. Once it is done, go back to Android Studio, and click File –> open.
  8. Choose the folder you put it in, and Android Studio will recognize the gradle files in it, and open your new app!

Hopefully that makes sense and keeps you from wasting as much time as I did. Most of you are probabl smart enough to know this already!

Linux – keep it simple.

Overclocked the Verizon Galaxy S5

Actually, I’m not the first one to do this. It’s been done dozens of times before, and quite frankly, to higher levels. So, why do I make my own kernel overclocked? Well, I do think there is one difference in my kernel overclocking than the others. I don’t increase the voltage while adding faster processing power.

Typically, in my kernels I try to focus on battery over performance. However, I like getting the most bang for the buck, too. So, in my kernel, I increased the frequency by 3%, but did not increase the voltage any. This allows the maximum benefit for the same amount of voltage, which equals an increase in performance, without an extra drain on the battery.

Okay, at least not a noticeable drain on the battery. Ohms law is still true, so the Resistance will drop slightly as the frequency went up, because of slightly higher heat, microscopically decreasing the resistance and changing the formula. However, when you increase the voltage, the Power formula changes dramatically.

For example, some fictitious numbers for conceptualization:

Power = Current x Voltage Let’s say, (P) 12 = (I) 2 x (E) 6.

If we increase the Voltage, the change is drastic: (P) 14 = (I) 2 x (E) 7.

If we don’t increase the voltage, the change is microscopic, only because the change in frequency will ultimately increase the heat (very slightly). In ohm’s law, that is I=E/R, so our formula looks like this: Power = Voltage/Resistance x Voltage, or (P) 12 = ([E] 6 / [R] 3) x (E) 6. So if the heat rises microscopically, then the semiconductor resistance lowers microscopically*, then the power will only change microscopically. So, our new fictitious formula looks like this: (P) 12.04 = ([E] 6 / [R] 2.99) x (E) 6.

Either way, you can check out the commit here:

https://github.com/alaskalinuxuser/android_kernel_samsung_klte/commit/dd3e95708f0f4166486fc4341691826ea303d993

Linux – keep it simple.

*Normally, in wire, heat increases cause the resistance to increase. However:

“In a semi-conductor, there is an energy gap between the (filled) valence and the (empty) conduction band. At zero temperature, no charges are in the conduction band and the resistance should be infinite as the system behaves basically like an insulator. If you turn on the temperature, some electrons will start to occupy the conduction band and thus contribute to conduction, lowering the [resistance].”  https://physics.stackexchange.com/users/661/lagerbaer