I don't think jaxx will have anything to support BCC, so if you want to be able to spend those, you should use a wallet that does or a wallet that has a fork that will. Personally, I recommend that you use Electrum or Core, and if you want to spend the BCC, you can easily use Electron Cash (fork of Electrum) and Bitcoin ABC (fork of Bitcoin Core). Since those two software are forks, you can use the same datadir or just copy your wallet file to the datadir that you are using for those software and be able to immediately spend the BCC coins.

You should stop using blockchain.info and instead use a desktop wallet like Electrum. Besides the fact that you are not necessarily the only person who can access your private keys with blockchain.info, IIRC blockchain.info won't have anything for supporting Bitcoin Cash so you won't be able to spend those if you wanted to.

Exporting and Importing private keys makes the private key exposed to many more things. When you are using Bitcoin Core, you are already in control of your private keys. The keys are protected by the software. If your wallet is encrypted (and it should be), then the unencrypted keys only exist in the software's allocated memory for a short period of time. However, as soon as you decide to export your private keys to import elsewhere, you are exposing your private keys to many many more things. They are now exposed to your video card and its drivers. It becomes exposed to your monitor, to your clipboard, to other software which may not have the same protection that Core provides, etc. Any one of these things, if infected with malware or if it has a vulnerability, could reveal your private keys to an attacker. Furthermore, you are now also vulnerable to shoulder surfers, or if you are in a public place, security cameras that can see your screen. Since exporting your private keys exposes it to so many more things that could have vulnerabilities, it is recommended for you to not handle them directly and let the software do it. This means that you shouldn't be exporting and importing keys.

Furthermore, exporting and importing keys implies that you will have multiple wallet instances with the same private keys. This is also inadvisable as having one of those instances compromised will compromise all of your private keys and all of your Bitcoin. That means that an attacker has more things he can try attacking. Doing that is also inadvisable since transactions that you make from one wallet instance may not necessarily appear on another wallet instance and result in you accidentally making double spends.

If you have a Bitcoin Core wallet and want to spend your BCC after the fork, you don't need to handle the private keys directly by importing and exporting them. Rather you can just install Bitcoin ABC and use your wallet file with Bitcoin ABC and spend your Bitcoin from there. Bitcoin ABC uses the same wallet format as Bitcoin Core as it is a fork of Bitcoin Core. The wallet.dat files are compatible with both clients.

Upgrade to Armory 0.96.1: https://btcarmory.com/0.96.1-release/

If you use Bitcoin ABC, then you can copy and paste the Bitcoin Core wallet.dat into the Bitcoin ABC datadir and it will work. Bitcoin ABC is forked from Bitcoin Core and, AFAIK, does not change the wallet format so the wallet files will be compatible.

You will need to use a wallet that supports BCC in order to be able to spend it. Right now, the only wallets I know of are Bitcoin ABC (based off of Bitcoin Core) and Electron Cash (based off of Electrum).

If you have a lot of RAM (4 or more), you can open the bitcoin.conf file and add the following line:
where <n> is an amount of memory in MB. If you have 4 GB RAM, I suggest you set it to 1000 so dbcache=1000. If you have 8 GB, I recommend 4000. If you have more RAM, you can set it to be higher, but after around 8000 setting it higher stops being any more helpful.

Your question is incredibly hard to understand.

What is "tx_hex"? Do you mean the hexstring of the raw transaction or the txid?

If you have a hexstring, you can use decoderawtransaction to decode the raw hex of a transaction.

No. That is completely incorrect. When you have ask for a transaction with getrawtransaction, you must have txindex enabled. The txindex means that Bitcoin Core's databases will have records with txids and the location of where the transaction data is stored in the blk*.dat files. When you request a transaction, it looks up the txid in the database and pulls it from the disk. Then it represents the binary data as a hex string.

Bitcoin Cash has implemented two way replay protection so any transactions created with a Bitcoin Cash wallet (e.g. Bitcoin ABC) will be invalid to the Bitcoin network and anything created with a Bitcoin wallet (e.g. Bitcoin Core) will be invalid to the Bitcoin Cash network.

Update to Armory 0.96.1 https://btcarmory.com/0.96.1-release/

Different block versions are present in both testnet and mainnet. It is used for signaling to activate soft forks. The first block version is version 1. Previous soft forks used a system called IsSuperMajority (ISM). These used fixed version numbers, consuming numbers 2, 3, and 4. We now use a new soft fork mechanism called BIP 9 Versionbits. BIP 9 specifies that all version numbers must have the top 3 bits of the version number be 001, which results in a version number of 0x20000000. From there, other bits are set for various soft forks, and unset once the fork has activated. For example, segwit uses bi 1, so setting bit 1 results in a version number of 0x20000002.

The alert system was removed for several reasons. First of all, it is a source of centralization. It was something which, as a protocol message, burdened other developers who needed to write in support for the alert system and the alerts could only be issued by few people. Secondly, it is actually not known who holds the alert key (even by those who are known to hold the key). Since there is only one key, as the key is given out to more people, the more people can get their hands on the key (by attacking someone who has it) and potentially cause trouble for the network. Lastly, the alert system actually has several DoS vulnerabilities which can be exploited by whoever has a copy of the alert key.

The alert system was a centralized source which imposed things on users, which is against the ideals of decentralization. Instead of forcing users to use the alerts system, a more decentralized approach has been adopted. Users are now supposed to choose where they wish to receive their information from. These can be from various Bitcoin news outlets, websites, forums, Reddit, etc. The user gets to choose how he wishes to stay up to date on the latest Bitcoin news. If there is a network emergency event, it is extremely likely that users will learn of it very quickly as all platforms will be warning of that event as soon as it is found out about. There is no need for an alert system when such information about network wide events will be posted to all Bitcoin forums and Bitcoin news sites will be publishing stories about it as soon as they hear of it. Even mainstream media may write stories about network-wide emergencies as Bitcoin is becoming popular enough for that to happen.

No. The fee only matters for the first confirmation. Confirmations after that are simply the count of blocks that have been built on top of the block that your transaction was included in. You have no control over how quickly you receive additional confirmations as that is all part of the Bitcoin mining process.

The private key is never revealed in signatures. Otherwise Bitcoin wouldn't be secure as signatures are used in transactions.

No. Do not delete any files. That will corrupt the databases and require you to redownload and verify the entire blockchain.

Just set the line I told you to set and restart Core. It will do everything automatically. If it is not, then you have created the file incorrectly. In that case, make sure the file is just bitcoin.conf. Make sure there is no extension like .txt on the file. If you are using windows, you should enable the "Show File Extensions" option so you can see the entire filename.

Use pruning. Go to the Bitcoin Core datadir (the path to which you can find by going to Help > Debug Window > Information and next the the "Datadir" label) and create a file named bitcoin.conf (just a text file, but without a .txt extension). Then add the following line to it:
Restart Bitcoin Core and you should see that it is no longer taking up so much space.

Yes. Signing anything will reveal the public key.

By "the fork", I assume you mean the Bitcoin ABC hard fork.

No, they have implemented two way replay protection.

100%. The fork is scheduled to occur when the median time is at or after August 1st, at 12:20 PM UTC.

Not this one. BIP 91 was supposed to prevent BIP 148 from activating and potentially causing a fork. Bitcoin ABC's fork is not BIP 148 (in fact it doesn't even have a BIP). BIP 91 itself could have caused many forks.

Your wallet files are corrupted, and that is what is causing the crash. Specifically, some keys are able to be decrypted, others are not, so the program exits out of an abundance of caution. This generally means that your wallet file is corrupted. To fix that, you use --salvagewallet, pywallet, or restore a backup. If none of those work, then the coins are lost.

No, you cannot do that or you will end up reindexing the whole database. The post that told you to do that was deleted for spamming and being outrageously incorrect and bad advice.

Resyncing the entire blockchain usually fixes the problem. It isn't pointless, it makes sure that you have a non-corrupted copy of the blockchain. You can't just use the data you already have if it is corrupted.