This is my first post to this group. I am looking at the screenrecord.cpp source code from android.googlesource.com. I found the following source links for the screenrecord.cpp file.
https://android.googlesource.com/platform/frameworks/av/+/android-4.4.2_r1/cmds/screenrecord/screenrecord.cpp
https://android.googlesource.com/platform/frameworks/av/+/aaa3f358410701710e31f31de62f0b4521989661/cmds/screenrecord/screenrecord.cpp
I think, #2 link is the latest source code for screenrecord.cpp. However, how can I know which source code is the latest one?
Any idea would greatly help me.
The answer depends on what you mean by "latest".
The currently-shipping version of Android, "KitKat" 4.4.2, comes with version 1.0 of screenrecord. That's what your first link points to.
The "master" branch of the AOSP source tree has the sources for screenrecord v1.1, which adds some new features. That's your second link. The newer version can be built and run on Android 4.4, but it's not checked into the 4.4 branch, so no devices I'm aware of currently ship with it.
Details about v1.1 are available here.
To see the latest in any git tree, you click on the link higher up the tree.
So for both the link you provided, click on higher up link and you will notice ending up here:
https://android.googlesource.com/platform/frameworks/av/+/master
Within the page is also indicated the latest commit number, and that is the latest as of anytime you are reading this article.
And then travelling down the link to reach the screenrecord.cpp again:
https://android.googlesource.com/platform/frameworks/av/+/master/cmds/screenrecord/screenrecord.cpp
now you notice that this link does not have any version anymore, but is tagged with a commit number - not at the link itself, but the first few lines of the page. That page is also the latest in development right now.
Related
today it's a shorter question I'd like to ask, to hear your opinions as I suppose some do this differently than others.
First of all,, I have an Android Studio project and am rather a novice on this subject of Android Development. That's why slight changes in the java or xml files could and did make my latest app unstable/ crashing.
Therefore I was asking myself wether Android Studio offers a way to backup stable builds - I could imagine this like a save-as option where you backup the working version and continue working on the the one but have a stable one backed up.
I know there's the export project function but I tried it out a couple of times and having worked on a project on the same device before, prior to reimporting a project causes an error and that's not the way I guess you should handle it in this situation.
I was looking at Google Cloud for using both version control and the option to commit new versions to the trunk and update them at a different location (different device). If that's the solution you propose, I need to look more closely into the documentation to get it up and running (set up the repository already but no clue how to commit changes/ versions).
So, long story short, what tool/ option do you prefer to have an export and a version control option unified for Android Studio?
Interested to hear and thankful for any advice on that!
There are multiple solutions,
Just find your solution/project in your file explorer and back it up, if you need it again just open the project with Android Studio. (not the most popular one)
Use a version control system like git. Link to tutorial (This is the most popular one), If u are unfamiliar with git, just google it and there are tons of examples and documentation. With git you can tag commits and after u mess up revert to the tagged commit
Git is the simpliest.
It's supported by AndroidStudio and later on you can upload your project to GitHub to access it from anywhere.
You can use it with terminal and shorcut keys, incons as well.
You also can make separate branches in order to make and test more versions parallely.
For more info take a look at: https://git-scm.com/about
and of course github: https://github.com/
Regards,
Cs
I noticed that the user will have to obtain a repo manifest file from
https://android.googlesource.com/platform/manifest
and choose a branch.
However I noticed something confusing. Take Android 6.0.1 (marshmallow) for example.
In the list of branches, some branches are named with revision numbers like below.
android-6.0.1_r65
android-6.0.1_r66
android-6.0.1_r67
android-6.0.1_r68
android-6.0.1_r69
android-6.0.1_r7
android-6.0.1_r70
android-6.0.1_r72
android-6.0.1_r73
android-6.0.1_r74
android-6.0.1_r77
android-6.0.1_r8
android-6.0.1_r9
However, there are also branches named with 'marshmallow' prefix like below.
marshmallow-cts-dev
marshmallow-cts-release
marshmallow-dev
marshmallow-dr-dev
marshmallow-dr1.5-dev
marshmallow-mr1-dev
I googled that 'mr1' is a shortened term for 'major release'.
If I want to build an AOSP for my android device, which one should I go for?
Should I go for the latest revision numbered branch, or 'marshmallow-mr1-dev'?
First of all you can check the origin of the tags and decide which you should use.
If your goal is to port the AOSP to device, make it perfect, pass CTS etc.. then the tags ex. android-6.0.1_r77 are a better option as often its the code will be considered official and if there is an error you can track it down. Even across all AOSP.
If you just want to play with it, and develop/get the latest code then should use the branch, but beware that all branches not necessarily sync across repositories and you might need to fix some framework/HAL issues so it will work.
m using the android youtube player OpenYouTubeActivity, i'm using the svn source code, not the jar file provided in the project. But it seems that this activity is not working after the 4.3 android releases. the video is shown half of the full screen, but everything else works fine. THis issue is already logged on the issues list on the project site.
Anybody has any clue, whats happening? Any solution is greatly appreciated.
Its always best to use the jars, because you get the latest compiled code and its easy for the maintainers to maintain versions. But I think on the code branch the fix here is to decompile the jar using an open source decompiler like http://jd.benow.ca/ and then copy the code as is.
Then you can see where the changes have been made.
DISCLAIMER
Please follow the licensing as the original wants it. I think its as per Apache, so make sure to include appropriate licensing information and credits and follow licensing laws.
I'm in need to get previous revisions of the Android Support Lib since there have been a couple weird issues introduced on the last two revisions 8, 9. I want to compare the source to figure out what could have happened and maybe patch it myself.
Essentially the issue is with the ViewPager not measuring correctly its width when used by a custom ViewGroup. Leaving the edge showing the next page slightly.
There are some (jar with source and javadoc) in Maven Central Repository.
Android Support Library is open source, you can directly check the source in GitHub project android/platform_frameworks_support. for instance, android.support.v4.view.ViewPager and click History at the top right corner of java code to see the complete change history.
Hope that helps.
You can find it here maybe. If not, I do not think they publish the link for the older versions.
However, you can still see what changes were made here. If that is not enough, ask a new question about the issue with ViewGroup and we will try to help.
You can find these support libraries at the Google download site:
https://dl-ssl.google.com/android
Revision 8
Revision 9
So I have managed to get a couple apps up on the marketplace only to have a stray thought of what is the best way to go about managing my projects/apps within eclipse to accommodate future updates to the marketplace. My question resides within Eclipse and what to do with my projects/apps as I apply updates.
Do I simply copy my project/app, paste it and the increment the version information accordingly? Or am I continuously working on my published project/app? Or...Is there a recommended/preferred method of going about this. Since they are up and good on the marketplace I am leery of doing something that will cause problems for me later on down the line.
And don't change the package name....correct?
This is what I currently have on the Marketplace...
Wind Chill Calculator
True Love Game
First of all, everyone's posts were very helpful and I have spent some time looking over documentation through the links provided.
So...and brace for impact as I say this. Being one who has NEVER used any form of SCM for my projects this is all new to me (as everyone's faces cringe), which is why I am asking the original question in the first place. I hate to say tell me anything without doing my research...so within the past few hours using git within eclipse I have gleamed the following:
Team > Share Project ...ignores...any tags(for version info)which is what I am after...commits...THEN
Clone? File -> Import -> Git -> Git Repository at this point once I have cloned my project do I create a new tag with the new version info, and go through the commit process again? If this is the case I now have two items in my Git Repository. One of which has the single tag of 1.0, and the other item which contains two tags 1.0 and 1.1, and when I look at the history I see two tags Version 1.0 and Version 1.1. Then I just switch between the resources I need from within the repository?
I just want to make sure my process is correct before I begin to implement some of this on existing projects that are pretty extensive already. As for the rest I am just going to learn on the fly...branches
You might want to use a revision control system like SVN or git or one of dozens of other options, and continuously update the single project in Eclipse. The benefit of using source control is that you can branch into a new project for major changes, update your existing code for minor changes, and tag the branches so you can revert back to an old snapshot in the future.
I personally use bitbucket which is hosted remotely and is free. It supports SVN and Mercurial.
No, dont change the package name, that will make it new app, instead of upgrade of original.
Use a version control system, like SVN.
Manage Tags for a complete working state of code(through svn), so you can always revert back to that tag.
When ready for new release, increment version no. etc and update on market...
EDIT After addition in question:
Don't get much confused with various GIT/SVN working.. There main purpose is that they will allow you to switch your code back and forth to any point in past, that allows you to code in a way properly knowing that you can always revert back to a Working state.. and it is definitely of much more benefit in a Team , when multiple people are working on same codebase and possibly same files...
Being a long-time user of SVN, I recommend subclipse (svn for eclipse). When you're ready to release another version of your app, create a 'tag' for the release version and you'll always be able to go back to that exact version.
SVN has excellent docs. There is also TortoiseSVN for repo work outside of eclipse.