BPi Android 4.2 Build Guide

72 21515
Honestly I am a bit of a gui fan myself and think that is a bit lack of Linux. But for compiling, I definitly agree with mattrix. The VM + WinSCP Solution works much smoother and I think it's good not wasting any of the VM ressources for drawing a gui, when this ressources could be used for Compiling itself

Edited by dlanor at Thu Nov 27, 2014 06:03

I don't want to start another of the ever-recurring 'Linux VS Windows' wars that plague many forums.
But there are a few things I need to respond to in a recent post of mattrix.

mattrix replied at Wed Nov 26, 2014 14:26 I was referring to developing in Linux.

On Windows, you are basically forced into using clunky programs.
That's entirely a matter of opinion.
Well written programs under Windows are no more or less likely to be 'clunky' than under any other OS.
That's entirely up to the programmers writing those programs.

That's why I have fell in love with Linux.
Here we're talking of software, not human relationships, so there is no need for such love to be exclusive, nor overprotective.
Both are natural responses, of course, but inappropriate in this context.

------  lots of stuff omitted, as it would be pointless to respond -----

I just thinking using a VM to emulate a GUI is a bit overkill.
I see nothing wrong with overkill, as long as it only consumes computer effort while easing human effort.

And your argument that we should use big clunky Os's for simply command line tasks because it's 2014 is completely wrong.
Please don't put words in my mouth that I never used myself.

I never said that you or others "SHOULD" use anything.
It's you who want to limit the implementation to console-only, while I want to allow either usage.
What's wrong with that ?

As for the 2014 reference, that simply meant that we are no longer forced to use console-only for everything, like we were forced to do back in the 70's when no GUI-based OS existed for the newly appearing microcomputers (as they were still called then, to separate them from 'mainframes').

And for generic computer usage, we definitely NEED to use GUI-based OS, since there are many things we just can't do in console windows.
(Seen any good console-based web-browsers lately... ? Or multi-window code editors ? (to mention something more relevant))

As for 'Clunky OS', both our methods involve installing what's essentially the same OS: A recent Ubuntu version
The only difference is that you are opposed to using its GUI.

It's more relevant now than ever - have you tried to do any development work on Windows 8? - took me 30mins to find something resembling a desktop!
I'm no fan of Windows 8 myself, though it does get a little better in version 8.1, but my real favorite Windows version is Win7pro_x64.
But I'm not married to the 'Windows' concept as such, though most of the other OS I use are run in VMs under VMware.

I don't see how you can start bashing command line, when all your instructions in your first post are command line.
And the fact that I did write those instructions in that way should have told you that I am in no way 'bashing" command line usage.
I never have.

But I have pointed out the obvious fact that there are limits to the usefulness of console windows, and some things are better done by GUI methods.

Can you please write a new tutorial for building Android in a GUI then?
Don't be absurd. The role of me as a supposed opponent of all console usage is a role you created in your imagination.
And now you demand that I defend that role, even though I had no part in it...???

Obviously the project build scripts and other components that were created for console-type invocation must be used that way.
But other parts of project maintenance, most importantly the browsing and editing of the sources, these require GUI-based methods and tools for best effects.
eg: How can you view many simultaneous related source files, to follow their intercactions, in an SSH console window ?

It's not about forcing people into an OS.
It's about giving the user / developer a STABLE development environment for a certain task (building Android)
Your instructions in this first post is forcing someone to use Ubuntu 12.04 or Ubuntu 14.04.
If it was using Vagrant, it would run in Windows, Linux and even MAC OS.
What are you talking about ?

My method is intended for use EITHER with a physical Ubuntu system or one emulated by VMware or VirtualBox or whatever.
And thus it will run on any system capable of using such emulators.

Your method is intended for use of a similar Ubuntu system emulated only by VirtualBox, managed by Vagrant.
And yet you consider my method more 'forced' than your own.

The real difference is that I recommend use of Ubuntu 14.04, which allows both GUI and console based work.
Whereas you recommend Ubuntu 12.04, and to use only console based work but no GUI work at all.
I also concede that your method simplifies installation for users, as they don't have to prepare a VM of their own.

Bottom line: I don't see these methods as opposed to each other.
They are just different approaches to handling the Android project builds, and there's no reason why they can't coexist.

I was like you when I started Linux - I was trying to make it like Windows.
Once I embraced SSH and terminal, WOW!
I think as you progress with Linux, you will start seeing what I mean.
I think not, as I'm no newcomer to command-line usage. I've been using it for quite some time (over 35 years).
Naturally I recognize that it's still useful for many things, but also that there are many things it just won't do well.

On Linux, 99% of everything can be done with terminal and notepad.
99% of everything you want to do, perhaps. Certainly a lot of development build work is by tradition console oriented.
But not 99% of generic computer usage. And not even all development work. There are GUI-based development environments too.
(Though none suitable for our project, as far as I know.)

But, at the end of the day - whatever works for you and what your comfortable with is good
Exactly! This is one thing we both agree on!

In closing:
I hope this post is not seen as aggressive, because it certainly isn't intended to be.

I just needed to clarify my position:
That I am neither opponent nor proponent on either side of the Linux VS Windows wars.
Nor am I in any way opposed to console command-line usage, where appropriate.
I just don't think it is appropriate for everything we need to do.

Best regards: dlanor

Edited by dlanor at Thu Nov 27, 2014 06:14
mattrix replied at Wed Nov 26, 2014 18:43
I've just re-read my comments and they come across quite.. angry.

Apologies if I've caused offense or came across nasty.
Don't worry about it. I've taken no offense, though I did feel obliged to respond, so as to clarify a few things.
As I said in that response post, I took your comments as 'overprotective' of your favorite tools, rather than as being 'nasty'.
It's a very common tendency to become attached to a set of tools we use often, and to respond emotionally if we think they're being unduly criticized.

We are all here for the same cause and too better the Banana Pi

I've decided to download and test your vagrant setup too, just to have a complete grasp of how it works.
But I'll probably keep using the VM I set up earlier for my real work, as I quite like the Unity GUI.

Best regards: dlanor

Ok, just found that r5p0 version of Mali drivers is available. So I added it to the lichee kernel to test it, after some tweaks it's building fine, and image is booting on it

Just made a commit and pushed it.

Yes, I also use Win7pro_x64.

My partner just got a new laptop with Win8.
Installed 8.1 and Classic Shell to make it slightly better.

I don't actually use Vagrant that much.
I use on my Windows laptop just for setting up the same environment that my production cloud server uses (Ubuntu 14.04)
(I mostly do web development stuff)

It just makes setting up shared folders, CPU, memory a lot easier than trying to configure in VirtualBox.
I never need to open VirtualBox.

You can also set the owner / group of these shared folders and the permissions.

This might help you solve that issue you had with VirtualBox?

Is it possible to build a custom kernel and custom android image with this guide? Because I want to remove wifi modules and add bluetooth support.

vicedens2002 replied at Fri Nov 28, 2014 07:22
Is it possible to build a custom kernel and custom android image with this guide? Because I want to  ...

Of course it's possible, but I for now the wifi and blutooth are disabled by default in our android base, do you erally want to go further to remove drivers ?

Mattrix, in my last push they were some temp files that are the result of previous built that should not have been pushed:
  • https://github.com/matthuisman/android/tree/master/lichee/linux-3.4/modules/mali/DX910-SW-99002-r3p2-01rel2/driver/src/devicedrv/mali/.tmp_versions
  • https://github.com/matthuisman/android/tree/master/lichee/linux-3.4/modules/mali/DX910-SW-99002-r3p2-01rel2/driver/src/devicedrv/ump/.tmp_versions

What should be the cleanesst way to removed them from the repository.

Still on the learning curve about git

ChrisP replied at Fri Nov 28, 2014 03:23
Of course it's possible, but I for now the wifi and blutooth are disabled by default in our androi ...

If wifi drivers are disabled then ok. I want to enable bluetooth atleast. I am making for a carpc I also want to connect a gps module. Any external gps module drivers preloaded in the android base?

ChrisP replied at Fri Nov 28, 2014 03:26
Mattrix, in my last push they were some temp files that are the result of previous built that should ...

Add a file called .gitignore and put the file names in here

Then, delete the files and do "git add -u" (stages deleted files)
Then your usual git commit and git push

You have to log in before you can reply Login | Sign Up

Points Rules