Related
"cupcake" development branch
A link to this was posted on the G1-Hackers mailing list. I haven't seen it here yet so I figured I would share. You can find the original post at http://source.android.com/roadmap/cupcake.
---------------------------------------------------------------------------------
"cupcake" development branch
From http://source.android.com/roadmap:
During Android's transition to anopen-source project, some development has continued to happen in aprivate branch. We are working to move the rest of these changes intothe open as soon as possible, and all future open-source work willhappen in the public git repositories. All changes that have alreadybeen submitted to the public repositories will be merged into the newercode base, so nothing should be lost.
The Android team has begun pushing these changes to the public git repositories, in the "cupcake" branch.
About this code drop:
The "cupcake" branch is a read-only mirror of the private Android branch.cupcake is still very much a work in progress. It is a development branch, not a release.
Thefirst drop is a large roll-up commit of all of the changes sincerelease-1.0. We will transition to regular, smaller roll-up drops,ultimately pushing individual commits.The cupcake branch willbe merged into the master branch, so that all of the public patches canbe used with the new code base. None of the commits in the publicrepositories will be lost, unless they no longer make sense or areobsoleted by the new code base. Due to the United States' holidayseason, though, this may not be finished until early January.
To check out the cupcake branch:mkdir cupcake # create a new client directory
cd cupcake
repo init -u git:/android.git.kernel.org/platform/manifest.git -b cupcake
repo sync
Notable changes introduced in cupcake:
Applications
MMS
New features
Save attachments from MMS.
Significant bug fixes
Faster conversation list scrolling
Email
Significant bug fixes
Accounts that were marked "never check" are not auto-checked.
Date & time displayed using user preference (e.g. 24 hr vs. AM/PM).
cc: displayed in message view.
Relaxed POP3 parser rules so it works with non-compliant email servers.
Password quoting bugs in IMAP. Makes it work for users with funny chars in their password (e.g. spaces).
Various sources of errors in auto & manual account setup.
Improvements on how we report various connection errors. Makes it much easier for user to diagnose failed account setups.
New-mail notifications for POP3 accounts.
Properly recover from POP3 connection failures, so that the next connection has a chance of working properly.
Remove automatic accounts setup entries that were broken or nottestable. Minor fixes to a few of the remaining entries. Improvementsto warning dialogs used for a few special cases.
New accounts are now set to check every 15 minutes (instead of defaulting to "never").
Fixed a bug causing approximately 1 in 25 outbound messages to freezeup the IMAP connection (to a Gmail based server) when transferred tothe Sent folder. This broke the entire connection so new messagescould not be downloaded either.
Unit test framework so Email can be extended & tested more reliably.
Fix IMAP manually-created accounts so message delete works properly.
Alarm Clock
Significant bug fixes
Alert now plays audio/vibe directly, rather than through AlarmManager.AlarmClock alert starts playing audio/vibe in its IntentReceiver,rather than on activity start. These changes should prevent alarms frombeing blocked by modal dialogs.
Package Installer
Significant bug fixes
Bugs related to replacing existing applications.
Settings
New features
New menu option to list running processes in Settings->ManageApplications.
Music
New features
Music playback fades in after suspending for phone call.New media search intent allows for 3rd party apps to launch or respondto media searches based on artist, album, or title.
Affects: MusicPlayer, YouTube, Browser applications.
Browser
New features
Updated WebKit browser core, synced with Nov 2008 WebKit version.
Support for new, optimized JavaScript engine (SquirrelFish).
Copy/ paste is enabled in the browser. To copy with touch, press and holdthe shift key and select the text. Releasing the shift key or endingthe touch drag copies the text. To copy with the trackball, press andhold the shift key, move the cursor to the selection start, click thetrackball, and move the trackball to the extend the selection.Releasing the shift key, or clicking the trackball a second time,copies the text.
Find is enabled in the browser. To find text, choose it from the menu and type the text to find.
Drawinghas been sped up substantially by supporting partial contentinvalidates and partial screen invalidates. Pages with animations are5x faster.
VoiceDialer
New features
VoiceDialer supports 'open app' command
Camera/Gallery
New features
Video recorder mode
Share intent for videos
Video thumbnailsLocal file playback
Download manager
New features
Support for HTTP codes 301, 302, 303 and 307 (redirects).
HTTP code 503 is now handled, with support for retry-after in delay-seconds.
Downloads that were cleanly interrupted are now resumed instead of failing.
Applications can now pause their downloads.
Retry delays are now randomized.
Connectivity is now checked on all interfaces.
Downloads with invalid characters in file name can now be saved.
"cupcake" development branch continued
Framework
New features
Support of touch events in WebView.New JavaScript engine (SquirrelFish) in WebView.
Input method framework, for soft keyboards and other on-screen inputmethods. Includes new APIs for applications to interact with inputmethods, and the ability for third party developers to write their owninput methods.
Access to the raw audio data for playback and recording from application code.
New PendingIntent.FLAG_UPDATE_CURRENT option.
Support for top-level boolean resources.
Tactile feedback to the LockPatternView. Tactile feedback can beenabled/disabled by going to Settings > Security & location andthen checking/unchecking "Use tactile feedback". Note that this can beused independently of the visual feedback of the lines ("Use visiblepattern"). Thus it gives users a middle ground between showing thelines on the screen and having no feedback at all.
PackageManager changes to support un-installation ofpartially installed applications. Added new flagPackageManager.GET_UNINSTALLED_PACKAGES to include partially installedapps in all relevant PackageManager api's. ManageApplications screennow lists such partially installed apps and the user can uninstallthese applications completely.
Support third party updates of system applications. Newmenu options in Settings->ManageApplications to list updated systemapplications.
Framework support to list current running processes. New API in ActivityManager.
Framework feature to declare required configurations by applications.New manifest attribute uses-configuration in android manifest.
Hardware accelerated video encode (video recorder) in opencore.
Simplified SREC speech recognition API available.
Streaming audio I/O for applications.
Significant bug fixes
Fixed issues with saving state in the view hierarchy, so that you canproperly subclass from something like TextView and create your ownstate that inherits from that provided by TextView.
TextView now implements onKeyMultiple(), so that flinging the trackballwill result in accelerated scrolling. This required some changes tomovement methods, and included some improvements to the accelerationcomputed when flinging.
Framework bug fixes in PackageManager to share/un-share permissions for applications with shared uid's.Significant rework of Settings->ManageApplications Performance and UI enhancements.
Anumber of settings in android.provider.Settings.System were moved toandroid.provider.Settings.Secure. Only system software can modify thesesettings. Additionally, a new permission, WRITE_SECURE_SETTINGS, isrequired to access these settings. The old constants in Settings.Systemhave been deprecated. It is possible to read settings values viaSettings.System using the deprecated constants. However, attempts tomodify these settings via Settings.System will result in a log messageand the setting value will be left unchanged.Many bug fixes in the media framework
Bluetooth
New features
Support for A2DP & AVRCP profiles.
Significant bug fixes
First connection after pairing always fails on many carkits.
Mini Cooper and some late model BMW cars fail to use Bluetooth or take 2 minutes for Phone Book transfer.
System software
New features
New kernel based on Linux 2.6.27.
Improvements to the wakelock API.
Work to transition to the USB Gadget Framework underway.
Basic x86 support.
Radio & Telephony
New features
SIM Application Toolkit 1.0.
Green CALL button is no longer a shortcut for "add a new call". Thishas been a rarely used feature and confusing if triggered accidentally.
Longer in-call screen timeout when using the speakerphone.
"Show dialpad" / "Hide dialpad" item added to the in-call menu, to make it easier to discover the DTMF dialpad.
Significant bug fixes
An obscure case where the Phone UI could cause the device to not go tosleep on its own. This would happen if user bails out of the in-callscreen by hitting HOME, followed by the call disconnecting remotely. Don't allow a single tap to open the in-call dialpad. Itis now required to touch and drag it. This makes it much harder toaccidentally open the dialpad by touching the screen with your face.
Developer Tools
New features
Enable handset manufacturers to extend the Android SDK with add-ons. SDK add-ons will include:
systemlibraries to let developers use additional APIs provided by handsetmanufacturers or from other 3rd party vendors that handsetmanufacturers chose to include
emulator system images,skins, and hardware configuration to let developers test theirapplications on their Android implementation
This is work-in-progress. Please note that the latest Android SDK (Android 1.0 SDK, Release 2) is not compatible with the SDKplugin in the new branch, please use ADT 0.8.0. SDK add-on support is planned for future SDK release.
Build System
New features
The functions in build/envsetup.sh should be much more useful
nice, this is some secret undercover stuff that is much needed!! you all rock!
hbguy
I'm wondering would it be available to install for non-jailbraked phone?
worry said:
I'm wondering would it be available to install for non-jailbraked phone?
Click to expand...
Click to collapse
We are talking about Android source code here. It would need to be compiled appropriately to even flash to any phone. Your phone would still subject it to the same key test before it will flash it. So, No this won't work... Yet. Hopefully we will find a way to sign these images with the OTA keys instead of just test keys as we do now.
"Chicken Soups for Andy Phones"
Yes, I am aware of you should compile it first.
So you are saying, since it is not officially signed by google, you'll be able to install it only on dev or has-proper-boot-image phones?
wait, how do we get all these updates in the future though? sdk?
also what you mean as finding a way to sign these images with ota keys instead of just test key? meaning with jf's mod rc30 we could get these update?
hbguy
man, well these were a few of the things that i wanted to see changed its good that they are keeping in touch with the ppl runnin the app. this is very compelling information. can i suggest and addendum to the title, something alluding to the "update" nature of this dev team. i dont think theres a date, but ill def be willing to pick a G1 back up for that, esp if they managed to make a few of the processes faster.
hbguy said:
wait, how do we get all these updates in the future though? sdk?
also what you mean as finding a way to sign these images with ota keys instead of just test key? meaning with jf's mod rc30 we could get these update?
hbguy
Click to expand...
Click to collapse
Cupcake can't be built to run on Dream hardware yet. Not to worry as an OTA RC with the cupcake code drops should be available by year's end or early Jan 09.
Support third party updates of system applications. New menu options in Settings->ManageApplications to list updated system applications.
Click to expand...
Click to collapse
I haven't had a chance to look into it too much but, depending on the applications and files made accessible, this looks very promising. Things like the autorotating browser, maybe even skinning, could potentially be "legitimized" and no longer require root.
so how would one go about compiling to run on the dream?
korndub said:
so how would one go about compiling to run on the dream?
Click to expand...
Click to collapse
Right now...... You wait. There isn't 100% of the code here. Nothing specific to the dream hardware etc. I am hopeful we will be seeing things come soon though.
As far as what I meant about the keys... Right now in order to be able to flash an update that is signed with test keys, aka the keys we have right now, you need to use an exploit to gain root access and modify the keys the system looks for when updating. There are two possible ways that I see to get OTA RC30 flashed with with an unofficial image. The first way is for some ingenious person to find an exploit that can be used to obtain root again and therefore be able to change the keys the system looks for. The other option would be for someone to come up with a way to sign the image with the OTA keys.
kronarq said:
Right now...... You wait. There isn't 100% of the code here. Nothing specific to the dream hardware etc. I am hopeful we will be seeing things come soon though.
As far as what I meant about the keys... Right now in order to be able to flash an update that is signed with test keys, aka the keys we have right now, you need to use an exploit to gain root access and modify the keys the system looks for when updating. There are two possible ways that I see to get OTA RC30 flashed with with an unofficial image. The first way is for some ingenious person to find an exploit that can be used to obtain root again and therefore be able to change the keys the system looks for. The other option would be for someone to come up with a way to sign the image with the OTA keys.
Click to expand...
Click to collapse
kronarq is there a way to merge the existing source with the cupcake to fill in the parts that are missing?
Anyone else having problems pulling the source with repo?
hbguy said:
nice, this is some secret undercover stuff that is much needed!! you all rock!
hbguy
Click to expand...
Click to collapse
This was not "undercover" work. Google wanted to be able to work on stuff, yet release the G1 with a semi-stable firmware.
kronarq said:
We are talking about Android source code here. It would need to be compiled appropriately to even flash to any phone. Your phone would still subject it to the same key test before it will flash it. So, No this won't work... Yet. Hopefully we will find a way to sign these images with the OTA keys instead of just test keys as we do now.
Click to expand...
Click to collapse
This won't be the case. This is an official Google release, meaning when they merge them together in January, they will release an OTA update with all of these features.
I'm hoping there will be an OTA update with all these new goodies, but just because google is rolling "cupcake" into the open-source project, that does not mean that it will get rolled out to our G1's. That's up to T-Mobile and HTC. Let's just keep our fingers crossed.
Ok, maybe I'm missing something, but where are people getting the idea that this is not dream specific? From how I read it these are all things that are being built into the main source and as such will be compiled as an ota as other updates have been done in the past. Someone enlighten me here as I'm just not seeing the "specific" requirements people are putting on this? I'm no coder, but it doesn't look like anything more then just enabling what was already there or planned on being there. [/rant?]
MMTest97 said:
Ok, maybe I'm missing something, but where are people getting the idea that this is not dream specific? From how I read it these are all things that are being built into the main source and as such will be compiled as an ota as other updates have been done in the past. Someone enlighten me here as I'm just not seeing the "specific" requirements people are putting on this? I'm no coder, but it doesn't look like anything more then just enabling what was already there or planned on being there. [/rant?]
Click to expand...
Click to collapse
Agreed... everything that is dream specific is either on the android git repository or can be extracted from stock G1 Firmware
MMTest97 said:
Ok, maybe I'm missing something, but where are people getting the idea that this is not dream specific? From how I read it these are all things that are being built into the main source and as such will be compiled as an ota as other updates have been done in the past. Someone enlighten me here as I'm just not seeing the "specific" requirements people are putting on this? I'm no coder, but it doesn't look like anything more then just enabling what was already there or planned on being there. [/rant?]
Click to expand...
Click to collapse
Everything in the open source repository should be non-device specific (with the obvious exception of stuff like binary drivers). The repo will build an emulator image. To build for dream, there are some additional instructions. However the cupcake branch cannot be built for Dream at this time, so it is definitely not Dream-specific.
Datruesurfer said:
Agreed... everything that is dream specific is either on the android git repository or can be extracted from stock G1 Firmware
Click to expand...
Click to collapse
The differences between G1 and the repo extend beyond just Google-proprietary apps. There are subtle differences in the framework too.
One of the things that I have been feeling is that the custom ROM community is growing at very high rate.
Going by the stats counters of various ROMs, we can peg CM, AOKP and Paranoid at 8mil, 4mil and 2mil each. There is also 1mil users of the mashup PAC-Rom.
Considering Omni is a huge project, this will race up to few millions soon. With a diaspora of 15-20 million users out there, we pretty obviously have a niche market of apps for these custom ROMs out there in the wild. In fact there are a lot of apps which are made specifically for custom ROMs.
For people who want to develop apps for these devices though, they are constrained to work with the AOSP SDK. But the custom ROM community has over the years made the the Settings and all Provider databases run on steroids with huge additions to them which can be brilliantly used to make more powerful apps.
Building an the SDK is in fact trivial
Code:
. build/envsetup.sh
make -j8 PRODUCT-sdk-sdk dist
or another way is
Code:
. build/envsetup.sh
lunch mako-userdebug
make -j8 sdk
The guys over there at Replicant already do make their own SDK with every release they make. I personally feel since at omni we are doing a great job of supportting so many devices, so many features and doing it in a well maintained way, we definitely should have our own SDK too.
I am a device maintainer at AOKP, and currently I am working on creating AOKP SDK too. (It does need pruning of the whole source a lot. Since the sdk building process validates the existence of each PRODUCT_PACKAGES call and does not ignore javadocs warnings)
http://goo.im/devs/kxp/android.jar
This here is a modified android.jar that can be replaced at sdk.dir/platforms/android-18/android.jar to support building apps using AOKP's custom variables and APIs.
Also such a venture helps building and testing of ad-hoc packages like AOKP's ROMControl or omni's OmniGears on studio/eclipse.
Sounds awesome
So what would be the effect in daily omni dev?
Are there things we should consider to make creating an SDK
as easy as possible?
maxwen said:
Sounds awesome
So what would be the effect in daily omni dev?
Are there things we should consider to make creating an SDK
as easy as possible?
Click to expand...
Click to collapse
I do not have a local copy of the omni source to be honest
I will sync up omni this weekend and start off with this. Will see what problems I face, and what can be done to keep the sdk always buildable.
SDK can be built out of pure AOSP source usually always.
Modified sources like that of a custom ROM often hacks with the build system (things like BUILD_PREBUILT and overriding LOCAL_MODULE etc as you know) which makes building sdk off the source of a custom ROM not that straight forward. right now i am in fact fighting with the AOKP source and trying to figure out what are the various things that need fixings.
Also in the framework packages, presence of lint warnings and other non-standard '@modifiers' like for eg. @hid makes sdk unhappy.
Replicant is an excellent examply of an Android fork that is always buildable for both devices as well as for the sdk.
As far as release cycle is considered, we can do that something like once a month or so ? The fully built zip of the sdk is ~350mb usually.
maxwen said:
Sounds awesome
So what would be the effect in daily omni dev?
Are there things we should consider to make creating an SDK
as easy as possible?
Click to expand...
Click to collapse
I do not have a local copy of the omni source to be honest
I will sync up omni this weekend and start off with this. Will see what problems I face, and what can be done to keep the sdk always buildable.
SDK can be built out of pure AOSP source usually always.
Modified sources like that of a custom ROM often hacks with the build system (things like BUILD_PREBUILT and overriding LOCAL_MODULE etc as you know) which makes building sdk off the source of a custom ROM not that straight forward. right now i am in fact fighting with the AOKP source and trying to figure out what are the various things that need fixings.
Also in the framework packages, presence of lint warnings and other non-standard '@modifiers' like for eg. @hid makes sdk unhappy.
Replicant is an excellent examply of an Android fork that is always buildable for both devices as well as for the sdk.
As far as release cycle is considered, we can do that something like once a month or so ? The fully built zip of the sdk is ~350mb usually.
Thanks for the tip! This is actually really nice.
We might build one as part of nightlies, that could come in handy. One thing to remember though is that the APIs we add to framework aren't meant to be used by apps directly as they are highly versatile and likely to change from day to day. We also enforce permission checks on everything we do to avoid any sneaky app.
XpLoDWilD said:
Thanks for the tip! This is actually really nice.
We might build one as part of nightlies, that could come in handy. One thing to remember though is that the APIs we add to framework aren't meant to be used by apps directly as they are highly versatile and likely to change from day to day. We also enforce permission checks on everything we do to avoid any sneaky app.
Click to expand...
Click to collapse
@XpLoDWilD
The @hide identifier is there precisely for the same reason
API's that should not be generated as stubs for android.jar should be under @hide
AOSP itself used @hide to keep some api's hidden which is not supposed to be used the by the casual app developer. (for example most provider apis are hidden only in sdk)
So if there is something that is REALLY volatile or something that should not be exposed into SDK (hacked up stuff ), they can be taken of using @hide
championswimmer said:
@XpLoDWilD
The @hide identifier is there precisely for the same reason
API's that should not be generated as stubs for android.jar should be under @hide
AOSP itself used @hide to keep some api's hidden which is not supposed to be used the by the casual app developer. (for example most provider apis are hidden only in sdk)
So if there is something that is REALLY volatile or something that should not be exposed into SDK (hacked up stuff ), they can be taken of using @hide
Click to expand...
Click to collapse
Which, so far, has usually been a case of "@hide everything" for most custom firmwares so as not to cause compatibility issues.
Changing this would require some pretty serious thought and would need to be done very carefully.
Entropy512 said:
Which, so far, has usually been a case of @hide everything" for most custom firmwares so as not to cause compatibility issues.
Changing this would require some pretty serious thought and would need to be done very carefully.
Click to expand...
Click to collapse
Okay as far as providing regularly updated APIs to app developers is concerned that would involve some thing like this
lunch a buildable device (full or sdk-eng will also do, or just simple lunch omni_mako-userdebug)
Code:
mka core; mka framework;
the following files
/home/championswimmer/jb-mr2/out/target/common/obj/JAVA_LIBRARIES/framework_intermediates/classes.jar
/home/championswimmer/jb-mr2/out/target/common/obj/JAVA_LIBRARIES/core_intermediates/classes.jar
(preferably renamed to core.jar and framework.jar) can be released then.
These, if added to external libraries in studio/eclipse (and has to be put higher in order of inclusion than android.jar from the sdk) can allow people to work using custom-added APIs of omni.
P.S. These libraries have stubs of @hide methods too. The @hide quantifier is not respected, and all APIs are exposed.
Entropy512 said:
Which, so far, has usually been a case of @hide everything" for most custom firmwares so as not to cause compatibility issues.
Changing this would require some pretty serious thought and would need to be done very carefully.
Click to expand...
Click to collapse
Okay as far as providing regularly updated APIs to app developers is concerned that would involve some thing like this
lunch a buildable device (full or sdk-eng will also do, or just simple lunch omni_mako-userdebug)
Code:
mka core; mka framework;
the following files
/home/championswimmer/jb-mr2/out/target/common/obj/JAVA_LIBRARIES/framework_intermediates/classes.jar
/home/championswimmer/jb-mr2/out/target/common/obj/JAVA_LIBRARIES/core_intermediates/classes.jar
(preferably renamed to core.jar and framework.jar) can be released then.
These, if added to external libraries in studio/eclipse (and has to be put higher in order of inclusion than android.jar from the sdk) can allow people to work using custom-added APIs of omni.
P.S. These libraries have stubs of @hide methods too. The @hide quantifier is not respected, and all APIs are exposed.
hacked this up
http://gerrit.aokp.co/#/c/14129/
anyone can feel free to port this for omni too. should be a matter of just changing the CUSTOM_NAME variable.
I'm going through all the features of the current version of Android Studio (version 1.0.2) and am frustrated by the documentation. There is existing documentation at JetBrains, but much of it appears to be out of date. I've wasted a fair amount of time trying to follow some sections of documentation only to finally decide that they are simply incorrect; then, of course, I have to work through the system by trial-and-error.
My question is: Is there any comprehensive documentation for the current incarnation of Android Studio? The best I've found so far is the book, "Android Studio Development Essentials" by Neil Smyth. Even that, however, spends far more pages on Android development in general than on the Android Studio too.
As an example, take a look at https://www.jetbrains.com/idea/help/accessing-module-settings.html. The first step is to bring up the Project Structure dialog. That comes up fine, but appears to have been completely redone and the very next step, "click Modules", doesn't appear to be pertinent any longer. Furthermore, the "Modules page" that that should bring you to doesn't seem to exist any more (at least I couldn't find it anywhere). This (i.e., module) information seems to be retained in the app.iml file (the module is called "app"), but I don't see where it can be modified in the GUI.
I have a few questions about Android Studio (given the above), but will post them separately.
Thanks for any pointers .
Barry
-------------
UPDATE:
From IntelliJ Support:
Online documentation is for IDEA, not for Android Studio. Android Studio is a narrow tool for Android development, so it doesn't have all IDEA features.
Android Studio is based on IDEA core code, but it is developed by Google.
Closing this item out. (Although, not to put too fine a point on it, I still don't know where good/accurate/current documentation is for Android Studio (Google?).)
CyanogenMod have the ability to scramble the location of numbers each time you turn on the screen to set the pin
I like it so much that feature
It will be possible to cherry pick? I never cherry picked anything, any help is good
Very grateful if someone can help me
You should look for an Xposed module that can to this
i just curious too for this stuff, like AOSP Based but have CMTE like Pure Nexus / DU
Any developer can help?
Cherry picking is just the action of merging a commit from a branch to your own branch. So it means you need to build the source, be it aosp or cm, to be able to cherry pick a feature. Theoretically, you can cherry pick any feature you want, as long as the code is open sourced, but it might be very hard to do so. For example, cherry picking CMTE will be a nightmare as I'm sure it needs a lot of stuff to be merged. Scrambled pins is likely much more easily cherry picked.
If you guys are wondering if you can 'cherry pick' some cm feature to the stock Google image, then the answer is no. Unfortunately, it doesn't work that way.
Gravitybox has PIN scramble under Lockscreen tweaks.
Dark_Eyes_ said:
Cherry picking is just the action of merging a commit from a branch to your own branch. So it means you need to build the source, be it aosp or cm, to be able to cherry pick a feature. Theoretically, you can cherry pick any feature you want, as long as the code is open sourced, but it might be very hard to do so. For example, cherry picking CMTE will be a nightmare as I'm sure it needs a lot of stuff to be merged. Scrambled pins is likely much more easily cherry picked.
If you guys are wondering if you can 'cherry pick' some cm feature to the stock Google image, then the answer is no. Unfortunately, it doesn't work that way.
Click to expand...
Click to collapse
There was a developer who used to port aosp, cm features into stock rom. I really miss that rom, Cataclysm.
Hmm yes but don't call it your own work and keep it closed source?
Sent from my Nexus 5 using XDA-Developers mobile app
I've been using Magisk for a long time so I'd like to try my hand at making something of my own. I'd like to make a module for LineageOS 18.1 which creates a quick settings tile that toggles a setting from developer options. My only programming knowledge is from a java class I took in high school a few years ago.
How should I go about this project? What do I need, how should I make it, etc...
What modifications to the project would I have to make to submit it to LineageOS Gerrit?
ethansoars said:
I've been using Magisk for a long time so I'd like to try my hand at making something of my own. I'd like to make a module for LineageOS 18.1 which creates a quick settings tile that toggles a setting from developer options. My only programming knowledge is from a java class I took in high school a few years ago.
How should I go about this project? What do I need, how should I make it, etc...
What modifications to the project would I have to make to submit it to LineageOS Gerrit?
Click to expand...
Click to collapse
I cant help you on the programming side of things - a google of "how to program a quick settings tile android" will get you close
A quick settings tile would normally be in the form of an app afaik, and require installing the Android SDK to get started, and is not something compatible with a magisk module
Also magisk modules cant be submitted to LineageOS, its nothing to do with them and not in any way mergeable with their code
I doubt you would get LineageOS to adopt your custom tile unless it did something that benefitted all users, they are pretty strict on their code, but you can always ask or submit and try your luck, but individual niche things are unlikely to get any traction
Prolly better off approaching as a standalone app and release if it does something you feel is widely useful....
Hope this helps
If you do want to do something in the form of a magisk module, heres what i recommend as a way of developing and packaging it...
GitHub - Zackptg5/MMT-Extended: Magisk Module Template Extended
Magisk Module Template Extended. Contribute to Zackptg5/MMT-Extended development by creating an account on GitHub.
github.com
and documentation:
Home
Magisk Module Template Extended. Contribute to Zackptg5/MMT-Extended development by creating an account on GitHub.
github.com