Afte enabling virtualzation on my HP Probook 6460b ( and disabling later), trying ./studio.sh in the bin folder is unable to start Studio and shows these lines:
-Xmixed mixed mode execution (default)
-Xint interpreted mode execution only
-Xbootclasspath:<directories and zip/jar files separated by :>
set search path for bootstrap classes and resources
-Xbootclasspath/a:<directories and zip/jar files separated by :>
append to end of bootstrap class path
-Xbootclasspath/p:<directories and zip/jar files separated by :>
prepend in front of bootstrap class path
-Xdiag show additional diagnostic messages
-Xnoclassgc disable class garbage collection
-Xincgc enable incremental garbage collection
-Xloggc: log GC status to a file with time stamps
-Xbatch disable background compilation
Uninstall the previous version
Delete .android and AndroidStudioProject files from C:\Users
Install android studio on a different partition
See if it runs on a physical device. Virtualization is needed only for emulators.
Do not import the previous configuration when asked.
Related
When I try to instantiate a VFP COM (OlePublic) DLL from my .NET web app running in IIS on Windows server 2016 I get:
Retrieving the COM class factory for component with CLSID {A55C4127-DDCB-4E5F-B69C-A7EAC83A83DC} failed due to the following error: 80004005 Unspecified error (Exception from HRESULT: 0x80004005 (E_FAIL)).
I was able to track it down (using Simon's comment) to it not being able to find vfp9r.dll:
Those files got installed w/ my InstallShield package under C:\Program Files (x86)\Common Files\Microsoft Shared\VFP:
vfp9r.dll
VFP9RENU.dll
vfp9t.dll
Why isn't "it" searching that dir? I got one server it is finding them under program files and another that isn't. How does that magic work?
update
if I install VFP 9, it will search that dir & successfully load it. So what is the VFP 9 install doing to my machine to tell "it" to search that dir not just the current dir & \SysWow64? 🤔
workaround
import these registry keys:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\VisualFoxProRuntimeMT.9\Shell\Open\Command]
#="C:\\Program Files (x86)\\Common Files\\Microsoft Shared\\VFP\\vfp9t.dll"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\VisualFoxProRuntime.9\Shell\Open\Command]
#="C:\\Program Files (x86)\\Common Files\\Microsoft Shared\\VFP\\vfp9r.dll"
(save the above 'script' as a .reg file and double click it to import it)
how I figured this out:
Hyper-V checkpoints so I could quickly go back and forth from a working to a non-working vm along w/ resetting after I did some test to find the minimal workaround
Search & export registry key w/ vfp9r.dll or vfp9t.dll
Compare exports via Notepad++ Compare Plus Plugin
The diff for vfp9t.dll was smaller so that was helpful. I grabbed the first key and that worked. Then I searched for the same-ish path for the vfp9r.dll export and grabbed that key.
According to https://developer.android.com/topic/performance/reduce-apk-size, I should be able to install Android Size Analyzer as a plugin, but nothing shows up.
Android Studio -> File -> Settings -> Plugin -> Marketplace -> search for "Android Size Analyzer"
UPDATE: 17th May 2022
After a lot of trials, errors & frustration, I was able to make it work. Here are the steps: (for MacOS)
Download the the plugin's zip folder from the Github https://github.com/android/size-analyzer/releases
Extract the zip and add the size-analyzer executable and the analyzer.jar to Users/<your_user>/Library/Android/platform-tools
(You can add the above files to any place but I bundled it with platform-tools because this location was already present in my $PATH variable. Wherever you place those two files, please make sure that this location is present in your $PATH variable else it won't work. Don't know how to set path variables? Please refer this https://techpp.com/2021/09/08/set-path-variable-in-macos-guide)
Now in your Android Studio Terminal, run the following command
size-analyzer check-project <your-path-to-project-directory>
(After above step, If the terminal complains like size-analyzer command not found, it means your $PATH variable is not set properly)
After analyzing the entire project, it shows output like this
The result analysis provides lots of suggestions and space saving options. Thank you Google for such amazing plugin : )
=================
OLD : 16th May 2022
The AS plugin Android Size Analyzer is deprecated! It's no more indexed on Plugin Market Place(You cannot install it directly from AS anymore).
I even tried installing the plugin from their GitHub Repo, but all in vain. When adding the plugin to studio from disk, the following error popped up.
Maybe you can try downgrading the studio and then install it.
Looks like, we'll be on our own for a while : (
I want VS let me use remote debbuging on Linux machine. I have downloaded necccessary packages and tools for this goal, so, I've denoted output and build directories. Build directory is created always successfully, but next step is Makefile that is not run, because CMakeList.txt is not sent from Windows machine.
I text in Additional Sources To Copy that this file should be copied, but I cannot know a reason of unsuccessful action. Only make command notifies me that this file does not exist. I guess this problem is in Visual Studio!
I have solved the problem and totally sure, that these things will exactly help you out!
https://developercommunity.visualstudio.com/content/problem/447310/2019-makefile-project-doesnt-copy-source-on-build.html
Fix the file
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\VC\VCTargets\Application Type\Linux\1.0\Linux.Makefile.targets
243 line, add this:
<Target Name="PrepareForNMakeBuild" DependsOnTargets="SetBuildDefaultEnvironmentVariables;SetUserMacroEnvironmentVariables;_RequiresRemoteConnection;_CopySources;">
Never use '~' when you denote pathes on remote machine in properties of debbuging, only like
/home/machine_name/project_name/$(SolutionName)/$(USERNAME)
When a windows cordova platform is added using:
cordova platform add windows
And the windows 10 project, inside visual studio 2015, is used to build the app package, the package validation fails, when it's validated using the "Windows App Certification Kit 10.0". The selected architectures are: x86 (release), x64(release) and ARM (release).
UTF-8 file encoding
Error Found: The UTF-8 file encoding test detected the following errors:
File C:\Program >Files\WindowsApps\BECC1407.AppXPTO_1.4.0.0_x64__6hmvhj7j5fc1t\www\cordova_plugins>.js is not properly UTF-8 encoded. Re-save the file as UTF-8 (including Byte >Order Mark).
File C:\Program >Files\WindowsApps\BECC1407.AppXPTO_1.4.0.0_x64__6hmvhj7j5fc1t\www\cordova-js->src\exec.js is not properly UTF-8 encoded. Re-save the file as UTF-8 (including >Byte Order Mark).
File C:\Program >Files\WindowsApps\BECC1407.AppXPTO_1.4.0.0_x64__6hmvhj7j5fc1t\www\cordova-js->src\platform.js is not properly UTF-8 encoded. Re-save the file as UTF-8 >(including Byte Order Mark).
...
File C:\Program >Files\WindowsApps\BECC1407.AppXPTO_1.4.0.0_x64__6hmvhj7j5fc1t\www\index.html is >not properly UTF-8 encoded. Re-save the file as UTF-8 (including Byte Order >Mark).
Impact if not fixed: HTML, CSS, and JavaScript files must be encoded in UTF-8 >form with a corresponding byte-order mark (BOM) in order to benefit from >bytecode caching and to avoid other runtime error conditions.
Bytecode generation
Error Found: The bytecode generation test detected the following errors:
File \?\C:\Program >Files\WindowsApps\BECC1407.AppXPTO_1.4.0.0_x64__6hmvhj7j5fc1t\www\plugins\cordo>va-plugin-splashscreen\www\windows\SplashScreenProxy.js has JavaScript syntax >or other problems.
File \?\C:\Program >Files\WindowsApps\BECC1407.AppXPTO_1.4.0.0_x64__6hmvhj7j5fc1t\www\plugins\cordo>va-plugin-splashscreen\www\splashscreen.js has JavaScript syntax or other >problems.
File \?\C:\Program >Files\WindowsApps\BECC1407.AppXPTO_1.4.0.0_x64__6hmvhj7j5fc1t\www\js\app.min.js >has JavaScript syntax or other problems.
...
Impact if not fixed: As a performance optimization to accelerate JavaScript >execution time, JavaScript files ending in the ".js" extension generate >bytecode when the app is deployed. This optimization significantly improves >start-up and ongoing execution times for JavaScript.
How to fix: You may need consider one or more of these steps to fix the issue:
- Avoid deploying the app by pressing F5 in Visual Studio, create an appx >package instead
- Ensure that event logging is enabled
- All JavaScript files are syntactically valid; otherwise exclude the >respective files from the package
- Please note that you should uninstall all previous versions of the app >before deploying
Otherwise exclude the respective files from the package.
I tried to submit but the apps fails.
Should not the cordova generate the project ready for publication?
Should I create a hook/nodejs file to rewrite all the files in utf8?
cordova build
does the trick on windows
cordova prepare changed it's behaviour since January 2016 - adding the BOM attribute now only takes place in the build step instead of the prepare step.
background:
CB-10193 Add BOM to www files at build stage instead of prepare
http://mail-archives.apache.org/mod_mbox/cordova-commits/201601.mbox/%3C05738d19a02748cb8d40df330d6b8216#git.apache.org%3E
http://markmail.org/thread/cg5s2jvxvyyqcqpd
--> the BOM gets added using the 'cordova build' command
see as well: https://issues.apache.org/jira/browse/CB-11241?focusedCommentId=15288933&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15288933
Sorry to ask such a noob question, but the NDK documentation is wrong (r7b):
If you are developing in Eclipse with ADT, use the New Project Wizard
to create a new Android project for each sample, using the "Import
from Existing Source" option and importing the source from
<ndk>/apps/<app_name>/project/. Then, set up an AVD, if necessary, and
build/run the application in the emulator.
There is no "apps" folder, and the samples do not contain a "project" folder. So ... what is the correct way to run a sample?
Also, can I configure Eclipse to build the C++ portion of the code automatically?
Click File | New | Project...
Choose Android project, Next
Project Name: This is the project name shown in Package Explorer. It is just a string stored in the .project file that Eclipse creates. No file or folder is created with this name, and the output binaries do not seem to contain this name.
Click "Create project from existing source"
Location: choose the project's root folder, e.g. .../android-ndk-r7b/samples/bitmap-plasma
Click Next and choose your target API. Eclipse does not seem to allow this to be changed later, at least not from the GUI. I don't know why Eclipse does not simply get this information from <uses-sdk> in AndroidManifest.xml or from the "target" line in default.properties. I also don't know why the two may be different (e.g. in the bitmap-plasma sample, target=android-9 but <uses-sdk android:minSdkVersion="8"/>.)
Click next and consider changing the "Package Name" field which defaults to "your.package.namespace". However, the project will run fine if you do not change this field. Leave "Create Activity" and "Create a Test Project" unchecked.
Click Finish. Eclipse will create numerous extra files (e.g. .classpath, .project, project.properties) and folders (bin, gen, assets) alongside the existing code. That's in addition to the output folders created by ndk-build (obj and libs).
Eclipse won't build the native code by itself, but it will automatically deploy the native code (e.g. libplasma.so) if it is aware of it. After you build the native code on the command line, e.g.:
C:\...\android-ndk-r7b\samples\bitmap-plasma>..\..\ndk-build
Gdbserver : [arm-linux-androideabi-4.4.3] libs/armeabi/gdbserver
Gdbsetup : libs/armeabi/gdb.setup
Gdbserver : [arm-linux-androideabi-4.4.3] libs/armeabi-v7a/gdbserver
Gdbsetup : libs/armeabi-v7a/gdb.setup
"Compile thumb : plasma <= plasma.c
SharedLibrary : libplasma.so
Install : libplasma.so => libs/armeabi/libplasma.so
"Compile thumb : plasma <= plasma.c
SharedLibrary : libplasma.so
Install : libplasma.so => libs/armeabi-v7a/libplasma.so
Right-click your project and choose "Refresh", otherwise Eclipse might fail to upload the native code when it starts the emulator.
Finally, to run the sample, right-click the project and choose Run As | Android application. See here about choosing which emulator is used.
See here about configuring Eclipse to build the native code automatically.
I am curious why NDK produces two *.so files with very different sizes for each ABI, e.g. it creates libs/armeabi-v7a/libplasma.so (15 KB) but also obj/local/armeabi-v7a/libplasma.so (63 KB). Anyone know the difference?
Instead of going the long winded way ( seasoned programmer love it - but for beginners). There is a way to build the native library in Eclipse and NDK.
1> First you need to make sure NDK path is correct in Windows -> Preference -> (tabs) Android -> NDK - If not set - point it to ndk directory.
2> Assuming you have you imported project as described above (New | Project | Create from existing code) - You right click the project and go to " Android Tools -> Add Native Support ..". If the path is set it will build the example. And then you can deploy it to the device or AVM by pressing the play button.
SOURCE
I'm working with Eclipse ADT and Android ndk 5b. My correct path to the project is android-ndk-5b/samples/project
When you import from existing source you have to choose a correct target, I use Android 2.3.3.
After, I've updated my project from command line, look this link, http://developer.android.com/sdk/ndk/overview.html
From the samples path write: android update project -p . -s and $Your_Path_Android_ndk/ndk-build
Finally, only run as android app in Eclipse and it's done
It seems that with Eclipse Juno, you can now
Click File | New | Project...
Under Android category select Android Project from Existing Code and click Next.
In Root Directory you can then browse and confirm your sample project location.
From here, Eclipse can automatically detect the jni and find the projects.
If this didn't work, go to terminal or command prompt and navigate to your project root directory (where you see jni folder). Then input
android update project -p . -t <your target level>
Here should be, e.g., android-9
After this, try again the initial steps.